Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 24E1B431FBF for ; Fri, 4 Dec 2009 00:58:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPznmh8VO4JQ for ; Fri, 4 Dec 2009 00:58:48 -0800 (PST) Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by olra.theworths.org (Postfix) with ESMTP id 701AD431FBC for ; Fri, 4 Dec 2009 00:58:47 -0800 (PST) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id nB48th5S013518 for ; Fri, 4 Dec 2009 19:55:43 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB48t3VP1138884 for ; Fri, 4 Dec 2009 19:55:03 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB48wj9c028642 for ; Fri, 4 Dec 2009 19:58:45 +1100 Received: from skywalker.linux.vnet.ibm.com ([9.77.199.28]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB48wUvR028474; Fri, 4 Dec 2009 19:58:36 +1100 From: "Aneesh Kumar K. V" To: Carl Worth , Notmuch list In-Reply-To: <877ht3hfh0.fsf@yoom.home.cworth.org> References: <877ht3hfh0.fsf@yoom.home.cworth.org> Date: Fri, 04 Dec 2009 14:28:22 +0530 Message-ID: <87fx7r5d5d.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 08:58:49 -0000 On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth wrote: > I just pushed out a nice set of changes to the emacs interface. Here's a > quick summary of what you can expect to get when you next update: > > * Much nicer looking presentation, (no more ugly reverse-video or > underlines on the message summary line). > > * More reliable message-visibility buttons, (using RET in the first > column of a message-summary line now works). > > * Space bar fixed to advance to next open message, (it was originally > written this way, but has been broken since we changed from global > to local toggling of hidden message parts). > > * Showing a thread where the search matches only a subset of the > thread now opens only the matched messages (in addition to unread > messages). > > This last feature is the big one---the rest all just happened to come > along at the same time. One thing that I often do is read some giant > thread and then tag a single message deep in that thread for dealing > with later. And previously, doing a search for that tag would bring back > the entire thread. Now, it opens only the message I'm actually looking > for. So this is a very welcome change > > And thanks to Bart Trojanowski for the groundwork for this change. I > think the vim interface has had this feature for a while, (or would have > if I had pushed all of Bart's changes earlier). > > Meanwhile, Keith and Eric gave me some helpful feedback about the > notmuch user-interface over lunch today, and in particular about the > handling of the "unread" tag. Here are some of the things discussed, > along with some things I'd like to change in response. > > I'm open to suggestions on all of these, and most importantly, wanted to > let people know about some upcoming user-interface changes before they > were in place and potentially surprising. > > * The magic space bar is too magic. Threads are separate conversations > so one key for paging through the current conversation shouldn't > also switch to the next conversation, (particularly when the > complementary key DEL doesn't reverse this behavior of SPACE). > > Recommendation: Make SPACE only page the current message. Recommend > that user use 'a' to advance to next thread, (or 'x' to exit back to > search results). > > * The unread tag is not handled transparently enough. Both Keith and > Eric complained of frequently being presented with messages as > "unread" that they had read before. (And I don't want to ever have > to manually think about whether to remove a thread as "unread".) > > Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and > 'x' mark remove the "unread" tag from all messages in the current > thread (as well as the "inbox" tag as currently). Also make 'n' and > 'p' remove the "unread tag as well. > > Followup: This frees up 'N' and 'P', so I'd like to use the for > "next message" and "previous message" and make 'n' and 'p' do "next > open message" and "previous open message". > > * Opening up unread messages in notmuch-show mode is not > helpful. Keith reads a lot of high-volume mailing lists by reading > the subject lines in search mode and then doing "* -inbox". He likes > that notmuch remembers that these messages are still unread, but if > he later searches for a single message that happens to be in a giant > thread of unread messages, then he wants to see just than one > message, not all of them. > > Recommendation: Make notmuch-show-mode open *only* messages that > match the search---not unread messages as well. At this point the > unread tag becomes just a hint to the user and won't be explicitly > handled differently by the interface, (other than that various > commands will remove the unread tag if present). The unread tag is > still useful for when searching for something like "I know I read > this message recently". > > Followup: I wonder if I would miss one feature here. If I'm > interrupted after reading part of a giant thread, currently I can > quite and when I come back notmuch will remember right where I was > while reading. One way to get this behavior back would be to make > SPACE remove the inbox tag from each message its scrolled off. I'll > have to think about that. > > * The current 'a' key in search-mode is unreliable. It seemed like a > good idea to make 'a' only archive messages that match the search, > but it's a flawed idea. Imagine the following scenario: Eric is > reading his inbox and sees some threads related to a boring > topic. He filters down to these with "f tag:boring". He's satisfied > with the search results, and hits 'a' on each thread and even sees > the "inbox" tag disappear from the presentation. But then when he > returns to his inbox search and refreshes, the boring threads > re-appear and have the inbox tag again. Ugh. The presentation is > inconsistent and things just feel unreliable and broken. > > And a related issue: > > * The '*' key in search-mode doesn't provide any feedback that it has > actually done anything, (none of the added/removed tags are changed > in the presentation). And hitting '=' isn't necessarily ideal since > it can make things irretrievably disappear, ('a' is different since > it allows the user to confirm that things are good before making > results disappear with '='). [*] > > Recommendation: Revert 'a' to act on all messages in a thread---not > only those that match the search results. Then change '*' to work by > walking the list and explicitly calling the same action as 'a' on > each line. This will provide the desired feedback and should be > plenty fast. Can we also get a facility to temporarily mark a message and apply tags on all marked message. In mutt terminology it is called 'tag'. Here is the use case: When reading mailing list with high volume we would really want to take a break in between reading mails or switch "folders". So if we do a * +done that would mean we add "done" tag on all the mails. But what we wanted was to do add done tag on the mails i looked till now. These marks should not go to database so there is no I/O involved when selecting the thread/mail. -aneesh