GNOME Bugzilla – Bug 105197
jwz threading irritating
Last modified: 2004-12-22 21:47:04 UTC
i have attached a thread that forces me to call jwz threading twice. it is compressed since its quite ot. maybe i should have tried to cut it a bit, but i hope it is ok so. i do not want to lose this (strange) behaviour. btw simple threading returns one thread.
Created attachment 14086 [details] compressed mail thread
I don't know whether that's a bug or simply an undocumented feature! I use JWZ myself to get rid of duplicate messages, like those that are left out of the first JWZ threading in your thread. If you *want* them in the thread, you can always use the second threading. I guess the real question is, what should a threading algorithm do about duplicates?
yeah. i'm sorry, i did not spend enough time finding out that these are duplicates. but on the other hand, its definitely irritating (at least for me) that using the same threading algorithm the second time yields another result. as you may have noticed, i do not really know the differences between simple and jwz threading, but if there is only this difference of duplicate finding, perhaps there should be a command for deleting duplicates. i mean: i will not delete a message until i know that this is a duplicate. deleting it just because there is a thread where it could fit into (where probably is already a twin), is no solution for me. If you think this is non-sense, simply document this feature somewhere :) btw. i had this problem twice with different cvs versions of balsa (creating duplicates while filtering, i think; at least i don't know where they else may come from). Was this a known bug, or do i have to look for failures on my_comp/mail_settings?
A bug leading to duplicate mails when using automatic filtering upon mail reception has been fixed (I guess in 2.0.6). I think there is a bug report related to applying filters on IMAP mailboxes, but nothing confirmated.
I quite often get duplicates, either by fcc'ing a copy of a message I send to a list or some other remote alias that I belong to, or because a copy is sent to me directly and also to a list. So they're nothing to get excited about, at least not for me. There are two key differences between simple and JWZ threading: 1. Simple threading looks only for the immediate parent of a message. If you have part of a thread, with some intermediate message missing, simple threading will not recognize it as a single thread. JWZ looks at all ancestors (= messages whose ids are references in the current message). 2. Simple threading is incremental: it modifies a current threading by checking whether any top-level message has an immediate parent elsewhere in the tree, and moving it if it finds one. This works quite well both for the initial threading (where the `current threading' is flat) and for rethreading after adding or removing messages. JWZ is designed* to be absolute: it builds a thread structure based on references, then checks every message to see if it's threaded below its closest ancestor, and moves it if it isn't. *Unfortunately, the current code implements that design correctly only for mailboxes with no duplicates (multiple messages with the same id). On each threading, it sees only the last message with a given id, which may or may not be the one it saw the previous time, depending on the mailbox sorting--hence the different results. Although I find a certain utility in the current behavior, it can only be characterized as buggy. It should be fixable.
Thank you for your work, peter. Your changes are working fine for me. But now you cannot isolate the duplicates. Would it be hard to create a menu entry for some command looking for duplicates and marking them (expanding their threads) or moving them directly to trash (maybe a message telling the user if there have been duplicates and how many)? At least me would love to see that :) I really appreciate your work.
Agreed: we now need some tool for managing dups--but I'm not sure exactly what function to implement! `Delete all duplicates' would probably be the simplest, but it might wind up deleting more than we want. Perhaps `select next duplicated message' would be safer.
You are probably right. Do you plan - to make this command "executable" everytime (how to indicate that there are no further duplicates) - or to make it depend on whether there are more duplicates (sounds like unnecessary work, since many people will not bother duplicates, slowing down balsa) I am happy about every reasonable method to remove the duplicates.
Remove duplicates available in balsa-2.0.10