1 Return-Path: <aneesh.kumar@linux.vnet.ibm.com>
\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 olra.theworths.org (Postfix) with ESMTP id 1A069431FAE
\r
6 for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 00:39:09 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
8 Received: from olra.theworths.org ([127.0.0.1])
\r
9 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
10 with ESMTP id QgKNNQkDyL8Z for <notmuch@notmuchmail.org>;
\r
11 Fri, 4 Dec 2009 00:39:07 -0800 (PST)
\r
12 Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147])
\r
13 by olra.theworths.org (Postfix) with ESMTP id B7625431FBC
\r
14 for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 00:39:06 -0800 (PST)
\r
15 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245])
\r
16 by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB48a2Dj003277
\r
17 for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:36:02 +1100
\r
18 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
\r
19 by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
\r
21 for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:39:04 +1100
\r
22 Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
\r
23 by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id
\r
25 for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:39:04 +1100
\r
26 Received: from skywalker.linux.vnet.ibm.com ([9.77.199.28])
\r
27 by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id
\r
28 nB48cqOW022255; Fri, 4 Dec 2009 19:38:57 +1100
\r
29 From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
\r
30 To: Carl Worth <cworth@cworth.org>, Notmuch list <notmuch@notmuchmail.org>
\r
31 In-Reply-To: <877ht3hfh0.fsf@yoom.home.cworth.org>
\r
32 References: <877ht3hfh0.fsf@yoom.home.cworth.org>
\r
33 Date: Fri, 04 Dec 2009 14:08:52 +0530
\r
34 Message-ID: <87hbs75e1v.fsf@linux.vnet.ibm.com>
\r
36 Content-Type: text/plain; charset=us-ascii
\r
37 Subject: Re: [notmuch] Recent (and forthcoming) improvements to the emacs
\r
39 X-BeenThere: notmuch@notmuchmail.org
\r
40 X-Mailman-Version: 2.1.12
\r
42 List-Id: "Use and development of the notmuch mail system."
\r
43 <notmuch.notmuchmail.org>
\r
44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
45 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
47 List-Post: <mailto:notmuch@notmuchmail.org>
\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
51 X-List-Received-Date: Fri, 04 Dec 2009 08:39:09 -0000
\r
53 On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth <cworth@cworth.org> wrote:
\r
58 > * The magic space bar is too magic. Threads are separate conversations
\r
59 > so one key for paging through the current conversation shouldn't
\r
60 > also switch to the next conversation, (particularly when the
\r
61 > complementary key DEL doesn't reverse this behavior of SPACE).
\r
66 > Recommendation: Make SPACE only page the current message. Recommend
\r
67 > that user use 'a' to advance to next thread, (or 'x' to exit back to
\r
70 Later you mention 'N' and 'n' to do the same task. Or are you suggesting
\r
71 that 'a' would move to the next task after marking the current task read ?
\r
74 > * The unread tag is not handled transparently enough. Both Keith and
\r
75 > Eric complained of frequently being presented with messages as
\r
76 > "unread" that they had read before. (And I don't want to ever have
\r
77 > to manually think about whether to remove a thread as "unread".)
\r
79 > Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
\r
80 > 'x' mark remove the "unread" tag from all messages in the current
\r
81 > thread (as well as the "inbox" tag as currently). Also make 'n' and
\r
82 > 'p' remove the "unread tag as well.
\r
85 ok that explains. But with Xapian ticket 250 we would definitely want
\r
86 some keybinding that move to the next mail without updating tags.
\r
90 > Followup: This frees up 'N' and 'P', so I'd like to use the for
\r
91 > "next message" and "previous message" and make 'n' and 'p' do "next
\r
92 > open message" and "previous open message".
\r
94 > * Opening up unread messages in notmuch-show mode is not
\r
95 > helpful. Keith reads a lot of high-volume mailing lists by reading
\r
96 > the subject lines in search mode and then doing "* -inbox". He likes
\r
97 > that notmuch remembers that these messages are still unread, but if
\r
98 > he later searches for a single message that happens to be in a giant
\r
99 > thread of unread messages, then he wants to see just than one
\r
100 > message, not all of them.
\r
102 > Recommendation: Make notmuch-show-mode open *only* messages that
\r
103 > match the search---not unread messages as well. At this point the
\r
104 > unread tag becomes just a hint to the user and won't be explicitly
\r
105 > handled differently by the interface, (other than that various
\r
106 > commands will remove the unread tag if present). The unread tag is
\r
107 > still useful for when searching for something like "I know I read
\r
108 > this message recently".
\r
110 > Followup: I wonder if I would miss one feature here. If I'm
\r
111 > interrupted after reading part of a giant thread, currently I can
\r
112 > quite and when I come back notmuch will remember right where I was
\r
113 > while reading. One way to get this behavior back would be to make
\r
114 > SPACE remove the inbox tag from each message its scrolled off. I'll
\r
115 > have to think about that.
\r
117 > * The current 'a' key in search-mode is unreliable. It seemed like a
\r
118 > good idea to make 'a' only archive messages that match the search,
\r
119 > but it's a flawed idea. Imagine the following scenario: Eric is
\r
120 > reading his inbox and sees some threads related to a boring
\r
121 > topic. He filters down to these with "f tag:boring". He's satisfied
\r
122 > with the search results, and hits 'a' on each thread and even sees
\r
123 > the "inbox" tag disappear from the presentation. But then when he
\r
124 > returns to his inbox search and refreshes, the boring threads
\r
125 > re-appear and have the inbox tag again. Ugh. The presentation is
\r
126 > inconsistent and things just feel unreliable and broken.
\r
128 > And a related issue:
\r
130 > * The '*' key in search-mode doesn't provide any feedback that it has
\r
131 > actually done anything, (none of the added/removed tags are changed
\r
132 > in the presentation). And hitting '=' isn't necessarily ideal since
\r
133 > it can make things irretrievably disappear, ('a' is different since
\r
134 > it allows the user to confirm that things are good before making
\r
135 > results disappear with '='). [*]
\r
137 > Recommendation: Revert 'a' to act on all messages in a thread---not
\r
138 > only those that match the search results. Then change '*' to work by
\r
139 > walking the list and explicitly calling the same action as 'a' on
\r
140 > each line. This will provide the desired feedback and should be
\r
143 With xapian ticket 250 doing a tag update per thread is going to be
\r
144 really slow right ?
\r
148 > Note: There are still use cases where the user might want to modify
\r
149 > the tags only on messages matching the search, (think, "remove from
\r
150 > inbox all messages from:someone"). So I'm aware that there's still a
\r
151 > hole in functionality here, but I really want to fix the current
\r
152 > inconsistency in the presentation. And I'm open to further
\r
153 > suggestions here.
\r
155 > Let me know if any of the above seems crazy,
\r
projects / notmuch-archives.git / blob