Re: Flat search and threaded views
authorYuri D'Elia <wavexx@thregr.org>
Thu, 4 Aug 2016 17:21:39 +0000 (19:21 +0200)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:22:19 +0000 (16:22 -0700)
21/04caf14cb0e16fd2d218974a2927eeec620634 [new file with mode: 0644]

diff --git a/21/04caf14cb0e16fd2d218974a2927eeec620634 b/21/04caf14cb0e16fd2d218974a2927eeec620634
new file mode 100644 (file)
index 0000000..c16d226
--- /dev/null
@@ -0,0 +1,99 @@
+Return-Path: <wavexx@thregr.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 arlo.cworth.org (Postfix) with ESMTP id 0FC1B6DE02B5\r
+ for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:21:50 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.159\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5\r
+ tests=[AWL=-1.148, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id GLO-wcDcUDSd for <notmuch@notmuchmail.org>;\r
+ Thu,  4 Aug 2016 10:21:42 -0700 (PDT)\r
+Received: from e.thregr.org (e.thregr.org [80.68.88.20])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id B9A566DE02B0\r
+ for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:21:41 -0700 (PDT)\r
+Received: from [2a02:27e8:20:9049:56ee:75ff:fe83:444c] (helo=localhost)\r
+ by e.thregr.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\r
+ (Exim 4.87) (envelope-from <wavexx@thregr.org>)\r
+ id 1bVMKy-0003oe-1U; Thu, 04 Aug 2016 19:21:40 +0200\r
+From: Yuri D'Elia <wavexx@thregr.org>\r
+To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org\r
+Subject: Re: Flat search and threaded views\r
+In-Reply-To: <877fbwv6h5.fsf@nikula.org>\r
+References: <87k2fwbl24.fsf@wavexx.thregr.org> <877fbwv6h5.fsf@nikula.org>\r
+User-Agent: Notmuch/ (https://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Thu, 04 Aug 2016 19:21:39 +0200\r
+Message-ID: <87eg64bgbg.fsf@wavexx.thregr.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 04 Aug 2016 17:21:50 -0000\r
+\r
+On Thu, Aug 04 2016, Jani Nikula <jani@nikula.org> wrote:\r
+>> I'd like to jump directly to the first unread message (and in detail, to\r
+>> the first message that actually matches the query!). It's really not\r
+>> great to have to find what message matched the query, especially for\r
+>> long-running threads.\r
+>\r
+> For me, hitting RET in search does show the first matching message in\r
+> the thread.\r
+\r
+Ok, I see now.\r
+\r
+The problem is that the search I've built includes both existing\r
+messages and unread ones (with a buffer of a day). So even though I get\r
+a new (unread) message, some existing messages in the thread also match.\r
+When reading a new thread started within the day, all messages match.\r
+\r
+So I have a different question:\r
+\r
+Can I customize how to jump within a thread? I understand 'unread' is\r
+nothing special and I'd like to keep it that way. So I'd like a quick\r
+way to navigate within a thread to skip to messages matching a certain\r
+tag (ie: unread).\r
+\r
+With that, I could setup a hook in notmuch-show to improve the behavior\r
+without making unread special.\r
+\r
+> The idea is that the unread tag gets dropped when the cursor visits the\r
+> region of an expanded message, in an approximation of when the user has\r
+> actually read the message. We spent quite a bit of time on this, and at\r
+> least I like this behaviour very much, especially with the red\r
+> overstrike on the unread tag in the buffer.\r
+\r
+I've seen this, but it wasn't clear how it was working. I see now the\r
+mechanism, but I need a convenient way to jump to tags in a show buffer.\r
+\r
+I have to say, as Matt experienced, I wasn't sure how messages where\r
+expanded until I read that message.\r
+\r
+> I suppose we could use a feature to tag matching messages from the\r
+> search view and expanded messages from the show view. You can of course\r
+> do this on the command-line.\r
+\r
+You mean 'notmuch tag'? Isn't this what '*' would do?\r
+\r
+>> Is there a way to sort the search (either tree/search) by subject or\r
+>> by author? Rarely useful, but it doesn't seem possible.\r
+>\r
+> I don't think so.\r
+\r
+I also didn't see a way to do that from the command line.\r