[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [Patch] Improved threading (by references and subject)
From:       Don Sanders <sanders () kde ! org>
Date:       2003-03-08 15:22:48
[Download RAW message or body]

On Saturday 08 March 2003 21:14, Till Adam wrote:
> On Wednesday 05 March 2003 12:43, Don Sanders wrote:
> > On Wednesday 05 March 2003 20:50, Till Adam wrote:
> > > On Wednesday 05 March 2003 08:25, Don Sanders wrote:
> > > > On Wednesday 05 March 2003 09:29, Ingo Klöcker wrote:
> > > > > I should have written what I meant, namely:
> > > > > .... Instead messages without subject prefix _and_ without
> > > > > In-reply-to header _and_ without References header should
> > > > > always be considered as top level messages. ...
> > > >
> > > > Ok, let's give that a try it. It should be a simple change.
> > > > Till do you want to do it or should I?
> > >
> > > I'll have some more time to work on this starting tonight, so
> > > unless you beat me to it, I'll look at doing it that way in a
> > > few hours.
>
> And as always with such things, I didn't find time to look at it
> that night.
>
> Ok, please find attached my current version of the improved
> threading patch. The changes are:
>
> I've further improved Don's fix for avoiding circular threading by
> also allowing messages to be used as parents for subject threading
> if they do have a ReplyToId, but the corresponding message is not
> to be found in this folder, and the same for ReplyToAuxId. What
> this means is, that subject threading works correctly now for
> threads which are cut of. That happens if you delete the upper part
> of a thread, for example.
>
> Unprefixed messages, that would be threaded by subject are forced
> to top level. This fixes the kde-cvs case as discussed. It does so
> by calling the new KMMsgBase::subjectIsPrefixed method which simply
> compares the MD5 hashes of the subject and its stripped variant. If
> they are the same, the subject is not prefixed. I have not added
> that information to the index mainly for two reasons. First, it is
> a bool and there is no logic to get/set bools in the index file.
> That would need to be added. Second, this code is called only when
> the sorted file needs to be regenerated, which happens if there is
> no sorted file yet, in which case there is no index either, so that
> doesn't help, or for new messages, in which case it isn't really a
> noticeable performance hit. There could also be the case that the
> sorted file is dirty, but the index is valid, I guess, but I've
> done some tests and it turns out that for example for my Inbox,
> subjectIsPrefixed is called for 362 of the 366 mails which results
> in an increase from 15ms to 16ms according to the timing macros
> that are there. For kde-cvs, it is called for 1004 of 1010
> messages, wich is an increase from 28 ms to 30 ms. For comparison,
> the whole of readSortOrder takes about 250 ms for kde-cvs with no
> local index or sorted file via imap. I am doubtfull that that
> justifies the index hit. It would be good to get more numbers from
> peoples folders, or maybe from people on low end hardware, I guess.
> Folders which are less problematic to thread, because messages in
> them can be threaded by replyToID or replyToAuxID, do not see any
> performance hit at all, since that check is only necessary if the
> message can't be threaded other than by subject.
>
> I needed to make a small change to kmkernel.cpp. The call to
> KMMessage::readConfig() needed to be moved up, since otherwise the
> replyTo and forward strings which are read from the config and used
> in the regexps of stripOffPrefixes were not initialized at the
> point where they are first used. I don't think that has any other
> side effects.

I've applied the patch and are testing it. Please give me a few days 
and then if I don't find anything wrong I think it's good to commit.

> > It's just the case of newbies replying to a message instead of
> > creating a new one that is annoying. I express my feelings about
> > this here:
> >
> > http://lists.kde.org/?l=kmail&m=104554502215219&w=2
> >
> > Out of interest does mutt do anything to break such threads?
>
> No, I don't believe it does.
>
> There is now only one difference between the threading in mutt and
> kmail, as far as I can tell from my folders. That is that mutt
> moves the whole thread to the position of the newest message in it,
> if sorting by received date/time. Kmail currently leaves the parent
> message where it is sorted according to its date and appends the
> newer message to that thread. I am not decided if that is something
> one wants or not. Opinions?

I think this sounds very promising. I think this behavior is what I 
personally would like. But I'm not sure how easy it will be to 
implement it efficiently, perhaps it's best to finish and commit the 
current patch before moving on.

Don.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]