display per message subjects in thread widget

[mjg]

Many senders to not quite grasp the concept of a mail thread, and this
"hijack" a thread by replying and changing the subject. In addition,
there may be good reasons for replies with changed subject, such as an
adjustment of status or the typical patch series threads with individual
topics.

Currently, all this information is hidden in collapsed view but may be
valuable for expanding the right message. Therefore, provide individual
subjects for the messages in thread view.

I'm open to suggestions on how to make this configurable ...

[pazz]

I'm with you on this one. Having individual subjects that can be displayed in thread mode would be nice.

There is one caveat: reading them from the email files on disk is costly, and this makes opening large threads slow.
This is why (I hope that's still the case) alot will not read thread messages at all unless they are unfolded when opening thread mode, and instead read all info from the notmuch index, which is fast.
Now, I'm not 100% sure if notmuch stores msg subjects. It looks like the notmuch2 bindings do not offer a subject getter on messages but that could be simply because no-one bothered to expose the underlying c function. Better double check.

[mjg]

I'm with you on this one. Having individual subjects that can be displayed in thread mode would be nice.

There is one caveat: reading them from the email files on disk is costly, and this makes opening large threads slow.
This is why (I hope that's still the case) alot will not read thread messages at all unless they are unfolded when opening thread mode, and instead read all info from the notmuch index, which is fast.
Now, I'm not 100% sure if notmuch stores msg subjects. It looks like the notmuch2 bindings do not offer a subject getter on messages but that could be simply because no-one bothered to expose the underlying c function. Better double check.

Oh bummer, after my patch that's an issue. I did notice that on large threads. I have to check the new bindings and, possibly, make the per-message-subjects appear only on demand or after expanding the thread (though that may look funny).

[mjg]

So, I checked, and notmuch stores from, subject and mail id in the db since around 2014 or so. The feature is NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES.

notmuch_message_get_header() (the C library function) gets those headers from the db and others from the message file. And that's the library function which is behind Message.header() in the new bindings (and Message.get_header() in the old ones). [And the slowdown that I mentioned was on the old SSD with slow db access.]

[pazz]

OK great, so this means we should expect large threads to build relatively fast (but still slower than without your patch).. Quoting Michael J Gruber (2021-01-01 18:46:00)

…

So, I checked, and notmuch stores from, subject and mail id in the db since around 2014 or so. The feature is NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES. notmuch_message_get_header() (the C library function) gets those headers from the db and others from the message file. And that's the library function which is behind Message.header() in the new bindings (and Message.get_header() in the old ones). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.*

[mjg]

I'll rebase shortly: There are indeed messages without subject where nm2 throws a LookupError. I have to catch that. Although it does not break anything as is you get a red warning to look at the log, which is not nice.

[pazz]

I think I already did that in 70d7cb6
Please rebase to the current master branch, cheers!

[mjg]

I think I already did that in 70d7cb6
Please rebase to the current master branch, cheers!

You did it for From, not for Subject, because Message does not store that before this PR. I don't mind rebasing if that makes the (clean) merge easier, of course.

[pazz]

You are right. Thanks!

[pazz]

I think this is nice, but would like to hear some other opinion on it, @lucc?
Ideally the feature would be configurable, not just because of potential speed issues but also because it "clutters" the interface somewhat and this may not be to everyone's liking.
For me, it often results in multi-line message summaries in case there are long subject lines.
Perhaps we could let users chose between three options:

1. no individual subject lines
2. all messages have subject lines, as in this patch
3. only the topmost message with the same subject displays the subject line. Meaning, only replies that change the subject would display the new one. Replies with the "same" (this is funky due to "Re*" prefixes) do not.
   Thoughts?