Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 66 / 895a0bb95ce635ccfd604c42c65e52979c72dd
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 24E1B431FBF\r
6         for <notmuch@notmuchmail.org>; Fri,  4 Dec 2009 00:58:49 -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 QPznmh8VO4JQ for <notmuch@notmuchmail.org>;\r
11         Fri,  4 Dec 2009 00:58:48 -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 701AD431FBC\r
14         for <notmuch@notmuchmail.org>; Fri,  4 Dec 2009 00:58:47 -0800 (PST)\r
15 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247])\r
16         by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB48th5S013518\r
17         for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:55:43 +1100\r
18 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])\r
19         by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id\r
20         nB48t3VP1138884\r
21         for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:55:03 +1100\r
22 Received: from d23av01.au.ibm.com (loopback [127.0.0.1])\r
23         by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id\r
24         nB48wj9c028642\r
25         for <notmuch@notmuchmail.org>; Fri, 4 Dec 2009 19:58:45 +1100\r
26 Received: from skywalker.linux.vnet.ibm.com ([9.77.199.28])\r
27         by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id\r
28         nB48wUvR028474; Fri, 4 Dec 2009 19:58:36 +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:28:22 +0530\r
34 Message-ID: <87fx7r5d5d.fsf@linux.vnet.ibm.com>\r
35 MIME-Version: 1.0\r
36 Content-Type: text/plain; charset=us-ascii\r
37 Subject: Re: [notmuch] Recent (and forthcoming) improvements to the emacs\r
38  interface\r
39 X-BeenThere: notmuch@notmuchmail.org\r
40 X-Mailman-Version: 2.1.12\r
41 Precedence: list\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:58:49 -0000\r
52 \r
53 On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth <cworth@cworth.org> wrote:\r
54 > I just pushed out a nice set of changes to the emacs interface. Here's a\r
55 > quick summary of what you can expect to get when you next update:\r
56\r
57 >   * Much nicer looking presentation, (no more ugly reverse-video or\r
58 >     underlines on the message summary line).\r
59\r
60 >   * More reliable message-visibility buttons, (using RET in the first\r
61 >     column of a message-summary line now works).\r
62\r
63 >   * Space bar fixed to advance to next open message, (it was originally\r
64 >     written this way, but has been broken since we changed from global\r
65 >     to local toggling of hidden message parts).\r
66\r
67 >   * Showing a thread where the search matches only a subset of the\r
68 >     thread now opens only the matched messages (in addition to unread\r
69 >     messages).\r
70\r
71 > This last feature is the big one---the rest all just happened to come\r
72 > along at the same time. One thing that I often do is read some giant\r
73 > thread and then tag a single message deep in that thread for dealing\r
74 > with later. And previously, doing a search for that tag would bring back\r
75 > the entire thread. Now, it opens only the message I'm actually looking\r
76 > for. So this is a very welcome change\r
77\r
78 > And thanks to Bart Trojanowski for the groundwork for this change. I\r
79 > think the vim interface has had this feature for a while, (or would have\r
80 > if I had pushed all of Bart's changes earlier).\r
81\r
82 > Meanwhile, Keith and Eric gave me some helpful feedback about the\r
83 > notmuch user-interface over lunch today, and in particular about the\r
84 > handling of the "unread" tag. Here are some of the things discussed,\r
85 > along with some things I'd like to change in response.\r
86\r
87 > I'm open to suggestions on all of these, and most importantly, wanted to\r
88 > let people know about some upcoming user-interface changes before they\r
89 > were in place and potentially surprising.\r
90\r
91 >   * The magic space bar is too magic. Threads are separate conversations\r
92 >     so one key for paging through the current conversation shouldn't\r
93 >     also switch to the next conversation, (particularly when the\r
94 >     complementary key DEL doesn't reverse this behavior of SPACE).\r
95\r
96 >     Recommendation: Make SPACE only page the current message. Recommend\r
97 >     that user use 'a' to advance to next thread, (or 'x' to exit back to\r
98 >     search results).\r
99\r
100 >   * The unread tag is not handled transparently enough. Both Keith and\r
101 >     Eric complained of frequently being presented with messages as\r
102 >     "unread" that they had read before. (And I don't want to ever have\r
103 >     to manually think about whether to remove a thread as "unread".)\r
104\r
105 >     Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and\r
106 >     'x' mark remove the "unread" tag from all messages in the current\r
107 >     thread (as well as the "inbox" tag as currently). Also make 'n' and\r
108 >     'p' remove the "unread tag as well.\r
109\r
110 >     Followup: This frees up 'N' and 'P', so I'd like to use the for\r
111 >     "next message" and "previous message" and make 'n' and 'p' do "next\r
112 >     open message" and "previous open message".\r
113\r
114 >   * Opening up unread messages in notmuch-show mode is not\r
115 >     helpful. Keith reads a lot of high-volume mailing lists by reading\r
116 >     the subject lines in search mode and then doing "* -inbox". He likes\r
117 >     that notmuch remembers that these messages are still unread, but if\r
118 >     he later searches for a single message that happens to be in a giant\r
119 >     thread of unread messages, then he wants to see just than one\r
120 >     message, not all of them.\r
121\r
122 >     Recommendation: Make notmuch-show-mode open *only* messages that\r
123 >     match the search---not unread messages as well. At this point the\r
124 >     unread tag becomes just a hint to the user and won't be explicitly\r
125 >     handled differently by the interface, (other than that various\r
126 >     commands will remove the unread tag if present). The unread tag is\r
127 >     still useful for when searching for something like "I know I read\r
128 >     this message recently".\r
129\r
130 >     Followup: I wonder if I would miss one feature here. If I'm\r
131 >     interrupted after reading part of a giant thread, currently I can\r
132 >     quite and when I come back notmuch will remember right where I was\r
133 >     while reading. One way to get this behavior back would be to make\r
134 >     SPACE remove the inbox tag from each message its scrolled off. I'll\r
135 >     have to think about that.\r
136\r
137 >   * The current 'a' key in search-mode is unreliable. It seemed like a\r
138 >     good idea to make 'a' only archive messages that match the search,\r
139 >     but it's a flawed idea. Imagine the following scenario: Eric is\r
140 >     reading his inbox and sees some threads related to a boring\r
141 >     topic. He filters down to these with "f tag:boring". He's satisfied\r
142 >     with the search results, and hits 'a' on each thread and even sees\r
143 >     the "inbox" tag disappear from the presentation. But then when he\r
144 >     returns to his inbox search and refreshes, the boring threads\r
145 >     re-appear and have the inbox tag again. Ugh. The presentation is\r
146 >     inconsistent and things just feel unreliable and broken.\r
147\r
148 >     And a related issue:\r
149\r
150 >   * The '*' key in search-mode doesn't provide any feedback that it has\r
151 >     actually done anything, (none of the added/removed tags are changed\r
152 >     in the presentation). And hitting '=' isn't necessarily ideal since\r
153 >     it can make things irretrievably disappear, ('a' is different since\r
154 >     it allows the user to confirm that things are good before making\r
155 >     results disappear with '='). [*]\r
156\r
157 >     Recommendation: Revert 'a' to act on all messages in a thread---not\r
158 >     only those that match the search results. Then change '*' to work by\r
159 >     walking the list and explicitly calling the same action as 'a' on\r
160 >     each line. This will provide the desired feedback and should be\r
161 >     plenty fast.\r
162 \r
163 Can we also get a facility to temporarily mark a message and apply tags\r
164 on all marked message. In mutt terminology it is called 'tag'. Here is\r
165 the use case:\r
166     When reading mailing list with high volume we would really want to\r
167 take a break in between reading mails or switch "folders". So if we do\r
168 a * +done that would mean we add "done" tag on all the mails. But what we\r
169 wanted was to do add done tag on the mails i looked till now. These marks\r
170 should not go to database so there is no I/O involved when selecting\r
171 the thread/mail.\r
172 \r
173 -aneesh\r
174 \r
175 \r
176 \r