[notmuch] Threading

[Carl Worth]

On Thu, 10 Dec 2009 20:08:18 +0100, Marten Veldthuis <marten at veldthuis.com> wrote:
> On a related note, what about communicating with people who press reply
> on an existing message, change the subject and start a new mail
> thread. Most mail clients will still insert the In-Reply-To header,
> which in this case is just wrong.

Just this morning I sent a mail to the notmuch list, which was a reply,
(and legitimately so), but also potentially of interest to everyone on
the list, (since it was regarding a bug fix unrelated to the original
topic of the thread I was replying to).

So I was stuck on whether I should break the thread or not, (at the
sending end). I guess I could have just sent a quick "this is pushed"
reply, and independently composed a separate message telling people
about the fix.

I ended up keeping the threading intact in that case, (which I think is
right). But maybe what we really want here is for notmuch to just
provide a bit more indication about subject changes (say, at the search
view). For example, I could imagine each subject change getting its own
line in the search view, (perhaps initially hidden with a button to
expand them). Obviously this would have to ignore trivial changes like
adding a "Re:" or a "[LISTNAME]" prefix.

> Ofcourse, it's their fault, but one can't educate the entire world. Is
> there anything like mutt has, to break a thread at the current message?

Not now. It would be a pretty trivial operation at the library level,
(just telling the library to generate a new random thread ID for a
particular message---and then to also recompute thread IDs for
descendant messages).

But I still have a hard time justifying user operations to manipulate
threading. The whole point of threading is to make it faster to process
and read messages. But manual operations like joining and splitting
threads seem like the user just doing more work, and that *after* having
read the messages. So that seems mostly backwards to me.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091210/e1c66001/attachment.pgp>