Threading

Threading

[Mark Anderson]

I was wondering if there's a way in notmuch to group un-associated threads into a single thread.

I have a bug tracking system that doesn't give me emails that thread naturally in notmuch.

I wouldn't mind writing a filter that could help identify a thread id which should apply to a message, and suggest that to notmuch.

Is there a method for this existing in notmuch yet?

--------------------
Mark Anderson

Re: Threading

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson <markr.anderson@amd.com> wrote:
> I was wondering if there's a way in notmuch to group un-associated
> threads into a single thread.

There's certainly nothing like that in notmuch currently.

Sup had user-level functionality in the interface for stitching messages
into a single thread, and I definitely think that that doesn't make any
sense.

> I have a bug tracking system that doesn't give me emails that thread naturally in notmuch.

I've seen similar things. Bugzilla emails at least all group into a
single thread in notmuch, but don't get nested correctly at all, and
that's really annoying.

> I wouldn't mind writing a filter that could help identify a thread id
> which should apply to a message, and suggest that to notmuch.

I think the right answer here is to fix the input that notmuch is
getting. Just ensure that each message has a proper In-Reply-To header
and all should be fine. If you can't fix the bug-tracking system to emit
proper email, can you apply your filter and rewrite the message as part
of delivery (before notmuch sees it)?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Threading

[Marten Veldthuis]

On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth <cworth@cworth.org> wrote:
> I think the right answer here is to fix the input that notmuch is
> getting. Just ensure that each message has a proper In-Reply-To header
> and all should be fine.

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.

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?

-- 
- Marten

Re: Threading

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

On Thu, 10 Dec 2009 20:08:18 +0100, Marten Veldthuis <marten@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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Threading

[Marten Veldthuis]

On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth <cworth@cworth.org> wrote:
> 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.

By the way, Outlook & Exchange suck (or at least some versions do), and
don't seem to generate In-Reply-To and References: headers. Just got a
mail which prompted me to write this mail. I'd really like to be able to
join messages in a case like this.

-- 
- Marten

Re: Threading

[Mark Anderson]

On Tue, 15 Dec 2009 16:54:20 +0100, Marten Veldthuis <marten@veldthuis.com> wrote:
> On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth <cworth@cworth.org> wrote:
> > 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.
> 
> By the way, Outlook & Exchange suck (or at least some versions do), and
> don't seem to generate In-Reply-To and References: headers. Just got a
> mail which prompted me to write this mail. I'd really like to be able to
> join messages in a case like this.

It's actually worse than that.  I was looking into why some of my
threads weren't coalescing.  Some of it seems to be a very difficult bug
DB that doesn't use identical Message-ID's to refer to the parent bug
mail.  I don't know how that works at all.  Sometimes it uses the same
Message-ID, but sometimes it changes a number in the ID.

However, this isn't the worst news, because I work with a lot of
Exchange users, and I noticed that their mail was also refusing to
thread.

I was looking at the message bodies, and they led me to these links
about mail processing.

The problem identified:
http://blog.postmaster.gr/2007/12/11/trying-to-make-use-of-outlooks-thread-index-header/

How to read it, or how Exchange goes its own way:
http://blog.postmaster.gr/2007/12/23/more-fun-with-message-threading/

With a fairly loose understanding of how notmuch detects threads, and
how much information it places in the Xapian database (only the
msg-id?), I can't suggest much of the how.

But I would like to propose that we consider handling the Exchange
non-standard threading method as well as the RFC822 threading in the
headers.

Reactions?

-Mark

Re: Threading

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

also sprach Carl Worth <cworth@cworth.org> [2009.12.11.0639 +1300]:
> On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson <markr.anderson@amd.com> wrote:
> > I was wondering if there's a way in notmuch to group un-associated
> > threads into a single thread.
> 
> There's certainly nothing like that in notmuch currently.
> 
> Sup had user-level functionality in the interface for stitching
> messages into a single thread, and I definitely think that that
> doesn't make any sense.

Why doesn't it make sense? Mutt does it too, and stitching means
actually (re)writing In-Reply-To and References headers.

I think this is one of the most useful "productivity features" in
mutt.

I also think that threading is a preference thing. As Carl said in
a later message:

> 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).

I often thread forwarded messages (and their followups) with the
thread because all my information management currently is
thread-oriented.

I think being able to freely break and tie threads in a trivial way
is a definite plus!

> 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.

Reading is one thing. Information storage and organisation is
another. After a message is delivered (and read) to my mailbox, it's
really mine and I can (and should be able) to affix it and integrate
it into my organisational scheme any way I want, don't you think?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"if there's anything more important than my ego,
 i want it caught and shot now."
                                                -- zaphod beeblebrox
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Threading

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Fri, 8 Jan 2010 16:12:38 +1300, martin f krafft <madduck@madduck.net> wrote:
> Reading is one thing. Information storage and organisation is
> another. After a message is delivered (and read) to my mailbox, it's
> really mine and I can (and should be able) to affix it and integrate
> it into my organisational scheme any way I want, don't you think?

A fair point.

I don't see this being something I'm going to spend any time
implementing. I just wouldn't use the functionality myself. But I would
be happy to integrate patches if someone came up with some.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Threading

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

also sprach Carl Worth <cworth@cworth.org> [2010.01.15.1108 +1300]:
> > Reading is one thing. Information storage and organisation is
> > another. After a message is delivered (and read) to my mailbox,
> > it's really mine and I can (and should be able) to affix it and
> > integrate it into my organisational scheme any way I want, don't
> > you think?
> 
> A fair point.
> 
> I don't see this being something I'm going to spend any time
> implementing. I just wouldn't use the functionality myself. But
> I would be happy to integrate patches if someone came up with
> some.

Maybe I should try to persuade you in person.

Just today I referenced a discussion I had with a client's ISP,
which was done via a web-based support system (custhelp.com). They
send you e-mail for every post you or they make to the thread, but
those e-mails do not reference each other. Fortunately, I stitched
them together and when I searched for the correspondence in my
mailstore, I had the entire thread available to me, which was handy
(thanks to mutt's useful thread handling abilities).

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"this week dragged past me so slowly;
 the days fell on their knees..."
                                                        -- david bowie
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]