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

List:       kmail-devel
Subject:    proposal for threading improvements
From:       Till Adam <till () adam-lilienthal ! de>
Date:       2003-02-23 13:32:17
[Download RAW message or body]

Hey folks,

like many other long time mutt users, I found threading support in kmail
lacking, when I recently tried to transition to a gui client (about the
25th attempt). While kmail appeared to thread just fine in my mailing
list folders, my Inbox somehow wasnt threaded the way I was used to in
mutt. Now, I know that threading by subject isnt implemented, but most
of the messages in my Inbox have In-Reply-To and References headers, so
those should be threaded correctly. What's so special about my Inbox, I
wondered. Well, I, like I imagine many others, keep my outgoing mail in
an Outbox and not in the same folder as the messages I reply to. Since I
have a lot of back and forth kind of email conversations, my Inbox tends
to contain only half of the conversation, namely all messages adressed
to me, not the ones I sent. This leads to the following problem:

alice
 |_till                     <- this mail is in Outbox
     |_alice                <- In-Reply-To points to my message

When trying to thread the last message, kmail looks at the In-Reply-To
header, doesnt find the message that it is pointing to, since that is in
my Outbox, and puts the message at toplevel.  What I would want to
happen would be:

     alice
      |_alice

Kmail needs to look at the References header and iterate from the back
of the list over all references messages until it finds one in the
current folder. I would guess, that in most cases the second to last
message will be in the same folder, thus providing a very sensible place
to thread the current message beneath.

Ok, having formed this theory, I went about implementing a patch to
prove it. I have local mboxes working as described above, but before
sending the patch, I'd like to discuss this with you folks, since it
turns out to be somewhat invasive. I did the following:

- in kmfoldermbox.cpp, don't truncate the References header string
  to the last one in the list, but keep the whole thing
- in kmheaders.cpp, check not only In-Reply-To but iterate over
  References from the back until a message in the current folder
  is found (both in readSortOrder and writeSortOrder)
- add References to KMMessage, KMMsgBase and
  KMMsgInfoPrivate
- add References string to the index (and bump the index
  version up)

Now, because the References string can be longish, I had to increase the
size limit in the STORE_DATA_LEN define, and of course having References
in there makes the index bigger. It might be sufficient to keep only the
last two mail ids in the References header to fix most cases and not
have to increase the index size so much. Would that be preferrable?

As for imap, from a cursory look over the relevant rfc, the ENVELOPE
doesnt contain the References header, so there would be some additional
work needed to get that and do the same magic for imap folders. I havent
tackled that yet, as I wanted to run this by you folks first.

Is all of this utter madness and someone has been selling me bad crack,
or would you consider taking such a patch? How about imap, what would
you consider a half way clean approach to this?

Cheers,

Till
_______________________________________________
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]