Only show each thread once per message list

[ChristophWurst]

Right now we still show the actual mailbox' contents and list messages. Threads are only shown when you open an individual message.

We should change the list to show threads in a sense that messages of the same thread are only shown once and at the position of the latest message.

[StCyr]

Also, you are right that the logic that applies to messages/envelopes is not the same at the one applying to threads. For example: Specific logic must happen when clicking on the "Delete" action of a thread

[StCyr]

Do you think we can say that only thread root messages have a non-null inReplyTo field once the message/envelope list has been cleaned from all threads' children (that's: the message/envelope list only contains messages that are not in a thread or are the root message of a thread).

Stated otherwise: Do you think that using the inReplyTo field is a proper way to discriminate thread root messages from non-threaded messages?

[ChristophWurst]

Stated otherwise: Do you think that using the inReplyTo field is a proper way to discriminate thread root messages from non-threaded messages?

Maybe we can use this as discriminator if we combine with References. Like if both headers are empty, this message has no ancestors. So it is a root (but possibly a root of an otherwise empty thread).

[alexanderdd]

Please keep in mind that in order to start a new thread, people often reply to some previous message and just change the subject. Hope this does not mess up your implementation idea.

[ChristophWurst]

Don't worry. The subject has little weight in this algorithm. You can check the implementation and the algorithms we based it on at #3355

[alexanderdd]

The subject has little weight in this algorithm.

Thats not good. So if someone takes an old mail, changes the subject and sends it, it will be grouped with the other, old mail? Because that is not the intention of the user, who deliberately changed the subject.

[StCyr]

The subject has little weight in this algorithm.

Thats not good. So if someone takes an old mail, changes the subject and sends it, it will be grouped with the other, old mail? Because that is not the intention of the user, who deliberately changed the subject.

Well, it’s 2020, users should know that the subject doesn’t govern threading algorithmes, but rather messageId, references, InReplyTo,... headers

I know it’s technical but users should be used to that kind of behaviour I believe

[ChristophWurst]

@alexanderdd we simply follow https://tools.ietf.org/html/rfc5256. No need to downvote explanations of how things are supposed to work. Please read that RFC and https://www.jwz.org/doc/threading.html. Things should be more clear afterwards.

[alexanderdd]

Ok then. I just wanted to point out that this will lead to a bad user experience, because users follow intution, not RFC. (That is why I downvoted StCyr's comment -- expecting the user to "know that subject doesn’t govern threading algorithmes, but rather messageId" is bad UX design - ask any UX expert).

Maybe it is possible for the mail app to assign a new messageId if the user changes the subject by hand -- should I open a separate issue for that?

[ChristophWurst]

We can talk about a feature request like allow users to branch off a thread into a new one or similar but the default should be to stay in the thread.