--- /dev/null
+Return-Path: <dme@dme.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 24C34429E25\r
+ for <notmuch@notmuchmail.org>; Tue, 31 Jan 2012 09:01:41 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 8Izxz26FJzAB for <notmuch@notmuchmail.org>;\r
+ Tue, 31 Jan 2012 09:01:40 -0800 (PST)\r
+Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
+ [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client\r
+ certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
+ 53E34431E64 for <notmuch@notmuchmail.org>; Tue, 31 Jan 2012 09:01:40 -0800\r
+ (PST)\r
+Received: by wgbdt12 with SMTP id dt12so180724wgb.2\r
+ for <notmuch@notmuchmail.org>; Tue, 31 Jan 2012 09:01:39 -0800 (PST)\r
+Received: by 10.180.90.194 with SMTP id by2mr12639800wib.5.1328029299210;\r
+ Tue, 31 Jan 2012 09:01:39 -0800 (PST)\r
+Received: from hotblack-desiato.hh.sledj.net\r
+ (host81-149-164-25.in-addr.btopenworld.com. [81.149.164.25])\r
+ by mx.google.com with ESMTPS id y1sm12982970wiw.6.2012.01.31.09.01.37\r
+ (version=TLSv1/SSLv3 cipher=OTHER);\r
+ Tue, 31 Jan 2012 09:01:38 -0800 (PST)\r
+Received: by hotblack-desiato.hh.sledj.net (Postfix, from userid 30000)\r
+ id 0CACF9FF33; Tue, 31 Jan 2012 17:01:36 +0000 (GMT)\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
+ notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 0/5 v3] reworked crypto toggle, plus a few other toggles\r
+In-Reply-To: <871uqf3kbl.fsf@servo.finestructure.net>\r
+References: <1327486729-18052-1-git-send-email-dme@dme.org>\r
+ <1327941064-20027-1-git-send-email-dme@dme.org>\r
+ <87pqe1w095.fsf@servo.finestructure.net>\r
+ <cund3a0b8ez.fsf@hotblack-desiato.hh.sledj.net>\r
+ <871uqf3kbl.fsf@servo.finestructure.net>\r
+User-Agent: Notmuch/0.11+137~g7cd907b (http://notmuchmail.org) Emacs/24.0.92.1\r
+ (x86_64-pc-linux-gnu)\r
+From: David Edmondson <dme@dme.org>\r
+Date: Tue, 31 Jan 2012 17:01:28 +0000\r
+Message-ID: <cunlionajrr.fsf@hotblack-desiato.hh.sledj.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 31 Jan 2012 17:01:41 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Tue, 31 Jan 2012 08:31:26 -0800, Jameson Graef Rollins <jrollins@finestr=\r
+ucture.net> wrote:\r
+> On Tue, 31 Jan 2012 08:09:08 +0000, David Edmondson <dme@dme.org> wrote:\r
+> > On Mon, 30 Jan 2012 09:47:34 -0800, Jameson Graef Rollins <jrollins@fin=\r
+estructure.net> wrote:\r
+> > > One thing I've noticed, which isn't actually part of this patch, is t=\r
+hat\r
+> > > the long-line truncation doesn't respect the indentation, which makes\r
+> > > things look strange.\r
+> >=20\r
+> > Which lines are getting wrapped in a way that you don't like? The header\r
+> > line? The headers? The body?\r
+>=20\r
+> Header lines, such as Subject, To, Cc, etc.\r
+\r
+You could try out id:"1327565871-19729-3-git-send-email-dme@dme.org".\r
+\r
+> > > But honestly I still don't like our method of displaying threads as a\r
+> > > giant chain of concatenated messages with indentation. But that's for\r
+> > > later work.\r
+> >=20\r
+> > It's inherited from sup, and is surely part of the "raison de notmuch"\r
+> > :-)\r
+>=20\r
+> Inheritance is not a good justification for anything, much less\r
+> questionable UI choices (I seem to have inherited baldness from my dad.\r
+> Thanks dad).\r
+\r
+I didn't suggest that inheritance was justification. Whether it's a\r
+questionable UI choice is largely a matter of personal preference. When\r
+Carl started the project he chose to follow sup's example in this\r
+respect. (Though sup is more aggressive in scrolling the display to the\r
+left to accommodate deep threads.)\r
+\r
+> Problems I have with the current approach:\r
+>=20\r
+> - thread structure is opaque. This is especially true with long\r
+> threads, where it can be next to impossible to see which messages are\r
+> replies to what. This is by far my biggest pet peeve with the current\r
+> format.\r
+\r
+A collapsed view of the current `notmuch-show-mode' buffer is not very\r
+different to a mutt index view.\r
+\r
+> - navigation through the thread is difficult. This is related to above.\r
+> There's no way to simultaneously see the current message and the\r
+> thread structure, which again, makes it very difficult to find\r
+> children and parents. This could possibly be fixed by having key\r
+> bindings that would navigate through parents, children and siblings of\r
+> the current message, but that might be tricky to implement.\r
+\r
+It would be relatively simple to add the bindings you describe, based on\r
+the computed thread depth of messages. So far I haven't particularly\r
+missed being able to do it.\r
+\r
+> - indentation of the entire message body is a really bad way to indicate\r
+> thread depth. I don't like how messages start to walk off screen as\r
+> threads get longer, or how copying regions of the body brings the\r
+> indentation with it. Your indentation toggling will improve this a\r
+> bit, though, but I still think it's a bandaid on the larger issue.\r
+\r
+The indentation works well until threads are more than about ten levels\r
+deep, I find. It becomes unworkable after about twenty levels (but\r
+conversations that deep tend to stress both the UI and myself in other\r
+ways as well).\r
+\r
+I don't copy regions of the `notmuch-show-mode' buffer, so that hasn't\r
+been a problem.\r
+\r
+> I must say that the approach I've been longing for is a modified version\r
+> of what mutt has: a top pain that is just the thread structure (with\r
+> nice branching lines), and a bottom pain that displays the current\r
+> message. I think that would be a much cleaner approach.\r
+\r
+Nothing precludes the implementation of what you describe. It's not hard\r
+to see how the two approaches could live side by side.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk8oHmgACgkQaezQq/BJZRaFzwCePk1ZdGWIysSyF9qCuxK6qJbp\r
+mFUAnilePPTh6wRKsnCntEb+Sk625hWH\r
+=hNug\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r
projects / notmuch-archives.git / commitdiff