--- /dev/null
+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 5E5A46DE02A6\r
+ for <notmuch@notmuchmail.org>; Thu, 11 Aug 2016 08:54:32 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.74\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-0.729,\r
+ SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SdnNXZaOGmHr for <notmuch@notmuchmail.org>;\r
+ Thu, 11 Aug 2016 08:54:24 -0700 (PDT)\r
+Received: from e.thregr.org (e.thregr.org [80.68.88.20])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id B91AB6DE0281\r
+ for <notmuch@notmuchmail.org>; Thu, 11 Aug 2016 08:54:23 -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>) id 1bXsJH-0001Zk-B0\r
+ for notmuch@notmuchmail.org; Thu, 11 Aug 2016 17:54:19 +0200\r
+From: Yuri D'Elia <wavexx@thregr.org>\r
+To: notmuch@notmuchmail.org\r
+Subject: Re: Flat search and threaded views\r
+In-Reply-To: <87eg64bgbg.fsf@wavexx.thregr.org>\r
+References: <87k2fwbl24.fsf@wavexx.thregr.org> <877fbwv6h5.fsf@nikula.org>\r
+ <87eg64bgbg.fsf@wavexx.thregr.org>\r
+User-Agent: Notmuch/ (https://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Thu, 11 Aug 2016 17:54:19 +0200\r
+Message-ID: <878tw3e1xw.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, 11 Aug 2016 15:54:32 -0000\r
+\r
+On Thu, Aug 04 2016, Yuri D'Elia <wavexx@thregr.org> wrote:\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
+I've tried to change my workflow to fit notmuch's, for example by\r
+narrowing my default searches only to only match unread messages.\r
+\r
+I'm feeling a bit mixed about the interface. This is not my first\r
+approach to tag-based email management (I actually still use mu4e). I\r
+wanted to give notmuch a try, mostly due to the way tags can be\r
+processed easily with afew.\r
+\r
+I like how the tagging workflow works, actually. I customized afew and\r
+the way default tags are assigned/managed. Batch-processing with afew is\r
+a breeze. I wrote my own plugin to implement MailMove the way I wanted\r
+in a few hours and overridden a few others. I'm quite happy about this.\r
+\r
+I just find the emacs interface a bit confusing.\r
+\r
+- Showing search results in threads, even after narrowing queries, is\r
+ not optimal. I'm shown a list of threads which contain tag:unread\r
+ messages, *but* the count is the number of messages in the thread\r
+ itself. I've been tripped multiple times by this.\r
+\r
+ I still think a flat search result would be better. I would like to\r
+ jump into the show buffer as it's being done currently (with the whole\r
+ thread) for additional context, but not for the direct search results.\r
+\r
+- Tagging individual messages is just cumbersome because of this. I\r
+ often flag individual ids that contain things that I need to act on\r
+ later. I cannot do this straight from the search results. I need to\r
+ read the thread and move the cursor to the appropriate message.\r
+\r
+- Even after reconsidering, I find that '*' will never do what I expect.\r
+ I'd like to tag matching ids (that is, what I'm seeing), not threads.\r
+ \r
+ People often hijack old threads just to find your address. I'm being\r
+ shown huge threads, but in reality I'm just getting a new message and\r
+ I don't really want to manage threads as well as messages. When\r
+ tagging, I almost always tag individual messages. When I tag threads,\r
+ generally is to 'kill' them using afew's KillThreadsFilter.\r
+\r
+- The unread mechanism itself is nice, but it doesn't work as you might\r
+ expect if you match also read messages. Easier navigation between tags\r
+ (such as "jump to the next unread message") is something I'm looking\r
+ for.\r
+\r
+- I patched notmuch to sync the TRASHED flag. Yes, deleting is a thing\r
+ if you use multiple clients. Would you consider accepting a patch for\r
+ this?\r
+\r
+- gnus-alias actually works better than mu4e's "current focus" (which\r
+ it's current identity mechanism). mu4e is a bit more comprehensive on\r
+ that front, but gnus-alias is smoother, which I didn't expect.\r
+\r
+I didn't still look at the notmuch-search sources. Do you think it would\r
+be hard to support showing individual ids only? Looks like it's easy to\r
+do from the cli, but might require too many conditions in the source.\r
+\r
+mu4e on the other hand offers a guile interface that can be used for\r
+filtering, so I'm not sure which is easier to do :P (implementing afew\r
+with guile, or tweaking notmuch search results).\r
projects / notmuch-archives.git / commitdiff