1 Return-Path: <wavexx@thregr.org>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by arlo.cworth.org (Postfix) with ESMTP id 5E5A46DE02A6
\r
6 for <notmuch@notmuchmail.org>; Thu, 11 Aug 2016 08:54:32 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org
\r
11 X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-0.729,
\r
12 SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled
\r
13 Received: from arlo.cworth.org ([127.0.0.1])
\r
14 by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id SdnNXZaOGmHr for <notmuch@notmuchmail.org>;
\r
16 Thu, 11 Aug 2016 08:54:24 -0700 (PDT)
\r
17 Received: from e.thregr.org (e.thregr.org [80.68.88.20])
\r
18 by arlo.cworth.org (Postfix) with ESMTPS id B91AB6DE0281
\r
19 for <notmuch@notmuchmail.org>; Thu, 11 Aug 2016 08:54:23 -0700 (PDT)
\r
20 Received: from [2a02:27e8:20:9049:56ee:75ff:fe83:444c] (helo=localhost)
\r
21 by e.thregr.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
\r
22 (Exim 4.87) (envelope-from <wavexx@thregr.org>) id 1bXsJH-0001Zk-B0
\r
23 for notmuch@notmuchmail.org; Thu, 11 Aug 2016 17:54:19 +0200
\r
24 From: Yuri D'Elia <wavexx@thregr.org>
\r
25 To: notmuch@notmuchmail.org
\r
26 Subject: Re: Flat search and threaded views
\r
27 In-Reply-To: <87eg64bgbg.fsf@wavexx.thregr.org>
\r
28 References: <87k2fwbl24.fsf@wavexx.thregr.org> <877fbwv6h5.fsf@nikula.org>
\r
29 <87eg64bgbg.fsf@wavexx.thregr.org>
\r
30 User-Agent: Notmuch/ (https://notmuchmail.org) Emacs/24.5.1
\r
31 (x86_64-pc-linux-gnu)
\r
32 Date: Thu, 11 Aug 2016 17:54:19 +0200
\r
33 Message-ID: <878tw3e1xw.fsf@wavexx.thregr.org>
\r
35 Content-Type: text/plain
\r
36 X-BeenThere: notmuch@notmuchmail.org
\r
37 X-Mailman-Version: 2.1.20
\r
39 List-Id: "Use and development of the notmuch mail system."
\r
40 <notmuch.notmuchmail.org>
\r
41 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,
\r
42 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
43 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>
\r
44 List-Post: <mailto:notmuch@notmuchmail.org>
\r
45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
46 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,
\r
47 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
48 X-List-Received-Date: Thu, 11 Aug 2016 15:54:32 -0000
\r
50 On Thu, Aug 04 2016, Yuri D'Elia <wavexx@thregr.org> wrote:
\r
51 > The problem is that the search I've built includes both existing
\r
52 > messages and unread ones (with a buffer of a day). So even though I get
\r
53 > a new (unread) message, some existing messages in the thread also match.
\r
54 > When reading a new thread started within the day, all messages match.
\r
56 I've tried to change my workflow to fit notmuch's, for example by
\r
57 narrowing my default searches only to only match unread messages.
\r
59 I'm feeling a bit mixed about the interface. This is not my first
\r
60 approach to tag-based email management (I actually still use mu4e). I
\r
61 wanted to give notmuch a try, mostly due to the way tags can be
\r
62 processed easily with afew.
\r
64 I like how the tagging workflow works, actually. I customized afew and
\r
65 the way default tags are assigned/managed. Batch-processing with afew is
\r
66 a breeze. I wrote my own plugin to implement MailMove the way I wanted
\r
67 in a few hours and overridden a few others. I'm quite happy about this.
\r
69 I just find the emacs interface a bit confusing.
\r
71 - Showing search results in threads, even after narrowing queries, is
\r
72 not optimal. I'm shown a list of threads which contain tag:unread
\r
73 messages, *but* the count is the number of messages in the thread
\r
74 itself. I've been tripped multiple times by this.
\r
76 I still think a flat search result would be better. I would like to
\r
77 jump into the show buffer as it's being done currently (with the whole
\r
78 thread) for additional context, but not for the direct search results.
\r
80 - Tagging individual messages is just cumbersome because of this. I
\r
81 often flag individual ids that contain things that I need to act on
\r
82 later. I cannot do this straight from the search results. I need to
\r
83 read the thread and move the cursor to the appropriate message.
\r
85 - Even after reconsidering, I find that '*' will never do what I expect.
\r
86 I'd like to tag matching ids (that is, what I'm seeing), not threads.
\r
88 People often hijack old threads just to find your address. I'm being
\r
89 shown huge threads, but in reality I'm just getting a new message and
\r
90 I don't really want to manage threads as well as messages. When
\r
91 tagging, I almost always tag individual messages. When I tag threads,
\r
92 generally is to 'kill' them using afew's KillThreadsFilter.
\r
94 - The unread mechanism itself is nice, but it doesn't work as you might
\r
95 expect if you match also read messages. Easier navigation between tags
\r
96 (such as "jump to the next unread message") is something I'm looking
\r
99 - I patched notmuch to sync the TRASHED flag. Yes, deleting is a thing
\r
100 if you use multiple clients. Would you consider accepting a patch for
\r
103 - gnus-alias actually works better than mu4e's "current focus" (which
\r
104 it's current identity mechanism). mu4e is a bit more comprehensive on
\r
105 that front, but gnus-alias is smoother, which I didn't expect.
\r
107 I didn't still look at the notmuch-search sources. Do you think it would
\r
108 be hard to support showing individual ids only? Looks like it's easy to
\r
109 do from the cli, but might require too many conditions in the source.
\r
111 mu4e on the other hand offers a guile interface that can be used for
\r
112 filtering, so I'm not sure which is easier to do :P (implementing afew
\r
113 with guile, or tweaking notmuch search results).
\r
projects / notmuch-archives.git / blob