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.

    Note: There are still use cases where the user might want to modify
    the tags only on messages matching the search, (think, "remove from
    inbox all messages from:someone"). So I'm aware that there's still a
    hole in functionality here, but I really want to fix the current
    inconsistency in the presentation. And I'm open to further
    suggestions here.

Let me know if any of the above seems crazy,

-Carl

PS. We also talked about new support for efficiently detecting file
addition, deletion, and renames. More on that when it becomes real.

[*] Yes, this is just a lame standin for a real undo feature. But until
we do have undo, it's an important standin.