Re: [PATCH] Fix typo in Message.maildir_flags_to_tags
[notmuch-archives.git] / 87 / dfbd7d4dab0a1cd05006fa492db77037dd5392
1 Return-Path: <cworth@cworth.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 olra.theworths.org (Postfix) with ESMTP id 454A4431FBC\r
6         for <notmuch@notmuchmail.org>; Thu,  3 Dec 2009 14:22:00 -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 5sfmGliih0G4 for <notmuch@notmuchmail.org>;\r
11         Thu,  3 Dec 2009 14:21:59 -0800 (PST)\r
12 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
13         by olra.theworths.org (Postfix) with ESMTP id 42ABF431FAE\r
14         for <notmuch@notmuchmail.org>; Thu,  3 Dec 2009 14:21:59 -0800 (PST)\r
15 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
16         id E597C2542FB; Thu,  3 Dec 2009 14:15:12 -0800 (PST)\r
17 From: Carl Worth <cworth@cworth.org>\r
18 To: Notmuch list <notmuch@notmuchmail.org>\r
19 Date: Thu, 03 Dec 2009 14:15:07 -0800\r
20 Message-ID: <877ht3hfh0.fsf@yoom.home.cworth.org>\r
21 MIME-Version: 1.0\r
22 Content-Type: multipart/signed; boundary="=-=-=";\r
23         micalg=pgp-sha1; protocol="application/pgp-signature"\r
24 Subject: [notmuch] Recent (and forthcoming) improvements to the emacs\r
25         interface\r
26 X-BeenThere: notmuch@notmuchmail.org\r
27 X-Mailman-Version: 2.1.12\r
28 Precedence: list\r
29 List-Id: "Use and development of the notmuch mail system."\r
30         <notmuch.notmuchmail.org>\r
31 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
32         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
33 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
34 List-Post: <mailto:notmuch@notmuchmail.org>\r
35 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
36 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
37         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
38 X-List-Received-Date: Thu, 03 Dec 2009 22:22:00 -0000\r
39 \r
40 --=-=-=\r
41 \r
42 I just pushed out a nice set of changes to the emacs interface. Here's a\r
43 quick summary of what you can expect to get when you next update:\r
44 \r
45   * Much nicer looking presentation, (no more ugly reverse-video or\r
46     underlines on the message summary line).\r
47 \r
48   * More reliable message-visibility buttons, (using RET in the first\r
49     column of a message-summary line now works).\r
50 \r
51   * Space bar fixed to advance to next open message, (it was originally\r
52     written this way, but has been broken since we changed from global\r
53     to local toggling of hidden message parts).\r
54 \r
55   * Showing a thread where the search matches only a subset of the\r
56     thread now opens only the matched messages (in addition to unread\r
57     messages).\r
58 \r
59 This last feature is the big one---the rest all just happened to come\r
60 along at the same time. One thing that I often do is read some giant\r
61 thread and then tag a single message deep in that thread for dealing\r
62 with later. And previously, doing a search for that tag would bring back\r
63 the entire thread. Now, it opens only the message I'm actually looking\r
64 for. So this is a very welcome change\r
65 \r
66 And thanks to Bart Trojanowski for the groundwork for this change. I\r
67 think the vim interface has had this feature for a while, (or would have\r
68 if I had pushed all of Bart's changes earlier).\r
69 \r
70 Meanwhile, Keith and Eric gave me some helpful feedback about the\r
71 notmuch user-interface over lunch today, and in particular about the\r
72 handling of the "unread" tag. Here are some of the things discussed,\r
73 along with some things I'd like to change in response.\r
74 \r
75 I'm open to suggestions on all of these, and most importantly, wanted to\r
76 let people know about some upcoming user-interface changes before they\r
77 were in place and potentially surprising.\r
78 \r
79   * The magic space bar is too magic. Threads are separate conversations\r
80     so one key for paging through the current conversation shouldn't\r
81     also switch to the next conversation, (particularly when the\r
82     complementary key DEL doesn't reverse this behavior of SPACE).\r
83 \r
84     Recommendation: Make SPACE only page the current message. Recommend\r
85     that user use 'a' to advance to next thread, (or 'x' to exit back to\r
86     search results).\r
87 \r
88   * The unread tag is not handled transparently enough. Both Keith and\r
89     Eric complained of frequently being presented with messages as\r
90     "unread" that they had read before. (And I don't want to ever have\r
91     to manually think about whether to remove a thread as "unread".)\r
92 \r
93     Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and\r
94     'x' mark remove the "unread" tag from all messages in the current\r
95     thread (as well as the "inbox" tag as currently). Also make 'n' and\r
96     'p' remove the "unread tag as well.\r
97 \r
98     Followup: This frees up 'N' and 'P', so I'd like to use the for\r
99     "next message" and "previous message" and make 'n' and 'p' do "next\r
100     open message" and "previous open message".\r
101 \r
102   * Opening up unread messages in notmuch-show mode is not\r
103     helpful. Keith reads a lot of high-volume mailing lists by reading\r
104     the subject lines in search mode and then doing "* -inbox". He likes\r
105     that notmuch remembers that these messages are still unread, but if\r
106     he later searches for a single message that happens to be in a giant\r
107     thread of unread messages, then he wants to see just than one\r
108     message, not all of them.\r
109 \r
110     Recommendation: Make notmuch-show-mode open *only* messages that\r
111     match the search---not unread messages as well. At this point the\r
112     unread tag becomes just a hint to the user and won't be explicitly\r
113     handled differently by the interface, (other than that various\r
114     commands will remove the unread tag if present). The unread tag is\r
115     still useful for when searching for something like "I know I read\r
116     this message recently".\r
117 \r
118     Followup: I wonder if I would miss one feature here. If I'm\r
119     interrupted after reading part of a giant thread, currently I can\r
120     quite and when I come back notmuch will remember right where I was\r
121     while reading. One way to get this behavior back would be to make\r
122     SPACE remove the inbox tag from each message its scrolled off. I'll\r
123     have to think about that.\r
124 \r
125   * The current 'a' key in search-mode is unreliable. It seemed like a\r
126     good idea to make 'a' only archive messages that match the search,\r
127     but it's a flawed idea. Imagine the following scenario: Eric is\r
128     reading his inbox and sees some threads related to a boring\r
129     topic. He filters down to these with "f tag:boring". He's satisfied\r
130     with the search results, and hits 'a' on each thread and even sees\r
131     the "inbox" tag disappear from the presentation. But then when he\r
132     returns to his inbox search and refreshes, the boring threads\r
133     re-appear and have the inbox tag again. Ugh. The presentation is\r
134     inconsistent and things just feel unreliable and broken.\r
135 \r
136     And a related issue:\r
137 \r
138   * The '*' key in search-mode doesn't provide any feedback that it has\r
139     actually done anything, (none of the added/removed tags are changed\r
140     in the presentation). And hitting '=' isn't necessarily ideal since\r
141     it can make things irretrievably disappear, ('a' is different since\r
142     it allows the user to confirm that things are good before making\r
143     results disappear with '='). [*]\r
144 \r
145     Recommendation: Revert 'a' to act on all messages in a thread---not\r
146     only those that match the search results. Then change '*' to work by\r
147     walking the list and explicitly calling the same action as 'a' on\r
148     each line. This will provide the desired feedback and should be\r
149     plenty fast.\r
150 \r
151     Note: There are still use cases where the user might want to modify\r
152     the tags only on messages matching the search, (think, "remove from\r
153     inbox all messages from:someone"). So I'm aware that there's still a\r
154     hole in functionality here, but I really want to fix the current\r
155     inconsistency in the presentation. And I'm open to further\r
156     suggestions here.\r
157 \r
158 Let me know if any of the above seems crazy,\r
159 \r
160 -Carl\r
161 \r
162 PS. We also talked about new support for efficiently detecting file\r
163 addition, deletion, and renames. More on that when it becomes real.\r
164 \r
165 [*] Yes, this is just a lame standin for a real undo feature. But until\r
166 we do have undo, it's an important standin.\r
167 \r
168 --=-=-=\r
169 Content-Type: application/pgp-signature\r
170 \r
171 -----BEGIN PGP SIGNATURE-----\r
172 Version: GnuPG v1.4.10 (GNU/Linux)\r
173 \r
174 iD8DBQFLGDhr6JDdNq8qSWgRAg+5AJ9nQA+VloFBZXm3/oXgVhFq5pNjNgCePxoj\r
175 5h7wY0+zFzg1KTMzFCGk6HM=\r
176 =gTj/\r
177 -----END PGP SIGNATURE-----\r
178 --=-=-=--\r