hijacked threads can be confusing in notmuch

hijacked threads can be confusing in notmuch

[Bart Trojanowski]

I'd like to see how other people feel about a problem I just ran into.

I wanted to look at the 'notmuch count' patch that Keith Packard posted
a couple of days ago (as I am porting his folder mode to notmuch.vim).

I was unable to find it using notmuch because he happened to post 3
patches in one go.  It's pretty common git practice, and by no means to
I hold Keith responsible :)

In mutt it looked like this:

  [notmuch] [PATCH 1/3] Make mouse-1 click in search view show thread
  └─>[notmuch] [PATCH 2/3] Add 'notmuch count' command to show the count of matching messages
    └─>[notmuch] [PATCH 3/3] Add notmuch-index mode to display message counts

... and in the mutt threaded display the relationship between the three
messages is pretty clear.

Now consider what happens when I run notmuch search 'notmuch count'.  I
get this:

  Today 02:15 [2/3] Keith Packard; [notmuch] [PATCH 1/3] Make mouse-1 click in search view show thread (inbox unread)

This thread happens to look completely unrelated to my search at first
glance.  So naturally, I dismissed it.  I finally clued in what was
happening and came back to it after.

On a related note, one mail related pet peeve I have is when people
reply to a random email in their mailbox when they actually intend to
start a new thread.  Doing that would totally mess up someone using
notmuch.  They could get search results with threads which have no
relevance to their actual search... at least at first glance.

So is there something better that we could do when detecting hijacked
threads like this?  Is it safe to cut threads when you notice a topic
change?  Or maybe it would be better to just mark such threads in the
output of notmuch-search (either a boolean flag, or a count of topic
changes).

Anyone know how Gmail deals with this?

Cheers,
-Bart

-- 
				WebSig: http://www.jukie.net/~bart/sig/

Re: hijacked threads can be confusing in notmuch

[Carl Worth]

On Sat, 21 Nov 2009 21:18:34 -0500, Bart Trojanowski <bart@jukie.net> wrote:
> In mutt it looked like this:
> 
>   [notmuch] [PATCH 1/3] Make mouse-1 click in search view show thread
>   └─>[notmuch] [PATCH 2/3] Add 'notmuch count' command to show the count of matching messages
>     └─>[notmuch] [PATCH 3/3] Add notmuch-index mode to display message counts
> 
> ... and in the mutt threaded display the relationship between the three
> messages is pretty clear.
> 
> Now consider what happens when I run notmuch search 'notmuch count'.  I
> get this:
> 
>   Today 02:15 [2/3] Keith Packard; [notmuch] [PATCH 1/3] Make mouse-1
>   click in search view show thread (inbox unread)

Hmm... that's a bug.

What notmuch *should* be doing here is taking as the subject of the
thread the subject of the first message in the thread that matched,
(rather than the subject of the first message in the thread).

The thread_create has all that information, (it constructs two
lists---one of all its messages, and one of matched messages).

Now the next step is still missing. Let's say that instead of 2/3
mesages matched in the thread, (and by the way, did you all now that
that's what's being reported there? it's not the number of unread
messages or anything like that, but the number of matched
messages). Anyway, let's say you had something like 1/20 there
instead. And let's also assume that there aren't any unread messages in
the thread.

Then when you go to view that thread you will see all the messages open,
and you won't have any information as to which message matched. What
*should* happen here is that only the messages that matched should be
open, and the messages that didn't match should be closed. Currently,
the various pieces of the system don't have access to the information
they need for this result. One way to do it would be to make "notmuch
search" return a list of message IDs rather than a thread ID and then
emacs could pass that list to "notmuch show". Alternately, the emacs
interface could pass the current thread ID to "notmuch show" but also
pass along the search string and then "notmuch show" could indicate
which messages matched the search.

Another thing to decide is how this relates with the default behavior of
opening unread messages but closing read messages. Would possibility
there could be to make that work just like any other search, just as I
described above. If we were to go that route, I think it might mean
getting rid of the distinction between "inbox" and "unread", and I'm not
sure I want to do that or not.

Anyway, I'd love to hear some ideas.

> On a related note, one mail related pet peeve I have is when people
> reply to a random email in their mailbox when they actually intend to
> start a new thread.  Doing that would totally mess up someone using
> notmuch.  They could get search results with threads which have no
> relevance to their actual search... at least at first glance.

Hopefully, the fix of displaying the subject from the first matched
message would help here.

-Carl