Summary: | Threading by subject and duplicates | ||
---|---|---|---|
Product: | [Unmaintained] kmail | Reporter: | Pierre Habouzit <pierre.habouzit_kde> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WAITINGFORINFO | ||
Severity: | wishlist | CC: | luigi.toscano |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | bad interleaving of received and sent mails |
Description
Pierre Habouzit
2003-07-31 11:35:19 UTC
I don't understand. Do you have Threading by Subject enabled for that folder? KMail normally threads only by References: and In-Reply-To: headers found in the messages. When it can find none, it won't thread, unless you enable the Threading by Subject feature. In that case, I don't know how it chooses a thread. Currently KMail adds messages with subject "Re: foo" below the first message with subject "foo" (when threading by subject). I agree that it would make much more sense to add the "Re: foo" message below the "foo" message which has the most recent date compared to the date of the "Re: foo" message. Example: That's how it should be: + foo 2003-07-30 +-- Re: foo 2003-07-31 ... + foo 2003-05-05 +-- Re: foo 2003-05-07 And that's how it's currently done (at least if one sorts by date from most recent to oldest): + foo 2003-07-30 ... + foo 2003-05-05 +-- Re: foo 2003-07-31 +-- Re: foo 2003-05-07 The problem is that this doesn't work with the currently used simple usage of a QDict<md5sum_of_message_id, KMHeaderItem> because "Multiple items can have the same key, in which case only the last item will be accessible using operator[]()." (cf. http://doc.trolltech.com/3.2/qdict.html#insert). So we probably have to use a QDict<md5sum_of_message_id, QPtrList<KMHeaderItem> > instead. Ok, I'll look into it. I've just committed some changes to the threading code that should have the desired effect. Can you test and close this wish if you are satisfied? Sorry, i was on vacation :) Yes, it's very better... but (yes there is still a but :/) it fact i know some people that _must_ use MUA that do not add references, but we have very long discussions. and with the old patch, it looked so : [mail0] +-mail[n] | +-my_response_to_mail[n] +-mail[n-2] | +-my_response_to_mail[n-2] +... | +mail[1] +-my_response_to_mail[1] now it looks like this (see screenshot) : [mail0] +-mail[1] +-mail[3] | +-mail[5] | | +-mail[7] | | +-my_response_to_mail[5] | +-my_response_to_mail[3] +-my_response_to_mail[1] which would be much better like this : [mail0] +-mail[1] +-my_response_to_mail[1] +-mail[3] +-my_response_to_mail[5] +-mail[5] for an explanation : i have a 'outgoing message' filter that keep the message in the folder of the people i'm writing to, and it seem that whereas the timestamps are interleaved, my responses are not interleaved. (i don't know if i'm very clear, my english is so poor ^^) thanks for your very beautiful work ! Created attachment 2288 [details]
bad interleaving of received and sent mails
one more remark, this threading capability does'nt work for threads where subject change like this : [subj 1] +-[Re: subj 1] +-[Re: subj 1] +-[Subj 2 (was: subj 1)] +-[Re : Subj 2 (was: subj 1)] when somebody replies to a mail with subject 'Re : Subj 2 (was: subj 1)' without any references, it creates a new thread, instead of appending it to the actual tree. maybe i must open a new bug ? If I understand this right -> then it should be rather easy to create : a. manual threading feeds b. define other threading methods by different headers Regular expressions search , found in "Find" functionality should be incorporated into "Filtering" mechanizm and expanded a bit , to let write things like "r/(n*)/$1" (if my perl is fresh :). By adding Action "Add to thread" , which would automatically create next action "Add header:" and would put "In Reference to:" or in "In Reply To:$1" headers, which triggerrs threading. Only would have look after order. That should also alow threading by "From" subject , or by entry in Address book ( recent emails). Plus , of course , ability to manually add messages to threads ( maybe creating a regex for filter to learn too next time add a another threading rule to this "thread" ? :) Sometimes by headers "From" sometimes by "In Reply To:" messages are added to threads, having "Show threads known senders" option in a view. This should also give and ability to add all known emails in "out" or other folders that correspond to the thread , as a view options/feature ? And, maybe just incorporate "Perl style" regex into every|some input boxes in Mail. For easy manipulation context rules, based on knowledge of Kmail in this istallation. Quote: "...it would make much more sense to add the "Re: foo" message below the "foo" message which has the most recent date compared to the date of the "Re: foo" message. Example: That's how it should be: + foo 2003-07-30 +-- Re: foo 2003-07-31 ... + foo 2003-05-05 +-- Re: foo 2003-05-07 ..." I disagree. The thread should always have the date of the last message posted. In fact any tree should have the last posted message so that the entire thread is pushed up to the top of the list. In the example below if the current date is 2003-07-31 I will be able to see my thread (if the thread is collapsed) in the list as I have received a new message today. If we display foo's date then since it's 2002-09-11 I will not be able to see the message in the list unless I scroll down to messages circa that date. So, the thread should not show the original message in question, it should become a sort of a marker or summary/digest for the entire thread, but most importantly, it has to always point to the freshest message in the thread. + foo 2003-07-31 +--- Re: foo 2003-07-31 +--- Re: foo 2003-01-01 +--- Re: foo 2003-01-01 +--- Re: foo 2002-09-23 +--- Re: foo 2002-09-12 +--- foo 2002-09-11 Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding. Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2. |