[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth <cworth at cworth.org> 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