Reply all - issue

[Jani Nikula]

On Sun, 27 Jan 2013, Robert Mast <beheerder at tekenbeetziekten.nl> wrote:
> Last week I studied many Windows-Mail User Agents with the conversation
> threading feature.
>
> None of them (SUP, mutt-kz(notmuch), Outlook 2010, Thunderbird with
> conversation thread plug in, Postbox, Evolution) could cope with the
> following case:

Apparently all of them obey the RFC 2822 References: and In-Reply-To:
headers for threading, and have no additional heuristics. I think it's a
good thing, but YMMV. I think mutt supports manual breaking and joining
of threads. The gmail web interface, OTOH, automatically breaks threads
on Subject: changes too [1].

> In our e-mail-discussions people often choose 'reply-all' to construct a new
> message with the same reciepients.
>
> They clear the body and the subject, but the hidden References: and
> In-reply-To: stay and should be cleared as well.
>
> Result is that this new subject drowns in an old
> conversation-thread-drilldown and this unpredictable behavior makes
> conversation threading useless.

The term you're looking for is thread hijacking. One could argue the
problem lies in the sender, not the recipient, and therefore should be
fixed in the sender end.

> I think of a fix that indexes the first dates of (stripped) subject-changes
> within threads, and with each first (stripped) subject change check the body
> on quotes of previous messages. If there is no quote to referenced mails
> then drop the reference and assign a new thread_id_ to the (stripped)
> subject.

Doing something like this would break threading for emailed patch series
[2], a very common practice in the open source world, including notmuch
development [3]. Indeed, the way gmail breaks patch threads, but then
joins different versions of the same patch email into new threads, is
very annoying IMO.

Also note that whatever you do, it should work the same way regardless
of the order in which messages the thread are indexed. Regenerating the
database should always end up in the same thread structure.

> After two days of studying I think the best place with the least
> interference with existing code is between 'notmuch new' and starting the
> MUA. Then the threads are in place in XAPIAN, and new thread_id_'s can be
> inserted.

The place you're looking for is probably
_notmuch_database_link_message() in lib/database.cc.

Patches, as they say, are welcome, but I believe for upstream notmuch
inclusion you'd need to address the issues I pointed out above.

HTH,
Jani.


[1] http://support.google.com/mail/bin/answer.py?hl=en&answer=5900

[2] http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project

[3] http://notmuchmail.org/pipermail/notmuch/2013/thread.html