Re: Provide an option to make thread summaries keep initial subject

[Thomas Schwinge <thomas@schwinge.name>]

Hi!

Regarding the following ideas -- from almost a decade ago ;-) -- is
anyone aware of any work in that area?

On 2012-09-25T15:31:37-0400, Austin Clements <amdragon@MIT.EDU> wrote:
> Quoth Olivier Berger on Sep 25 at  6:03 pm:
>> Whenever a participant changes the subject in the middle of a thread,
>> the summary reported by notmuch search will change.
>> 
>> However, the result is that some mails tend to "disappear" from search
>> results, when (bad) participants reply instead of composing a new mail,
>> and change a subject (see
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699 for more details
>> on that problem, and a discussion). Of course, they're still there, but
>> their subject being masked, one may then grep or C-s for a particular
>> subject and miss them.
>> 
>> I think it would be interesting to allow notmuch to potentially keep the
>> original subject and not the most recent one for the thread summaries.
>> 
>> What do you think ?
>
> I think this would be fantastic.  I've proposed unconditionally
> showing the earliest subject before and it seems that people who
> correspond mostly with those who have good threading etiquette would
> prefer this change, but those who correspond with more people who use
> 'reply' like an address book prefer the current behavior.

And then, especially, the following one would be very useful for me:

> Another option, which I'd like to experiment with but haven't found
> the time, is to show *all* distinct subjects for matched messages in a
> thread (modulo "Re:", etc) in the summary buffer, probably on multiple
> lines.  Since most threads only have a single unique subject, they
> would appear just as they do now, but it would be clear when someone
> (or something, like git) changed the subject mid-thread.  This
> approach would be far more robust while retaining good usability, but
> it would require more code than just changing our subject-picking
> heuristic.

I'm aware of notmuch Emacs UI 'notmuch-tree' and 'notmuch-unthreaded',
but these are not quite what is desired here: too verbose, compared to
the concise display variant of 'notmuch-search'.


Grüße
 Thomas\r