From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/10124 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Ack! nnfolder+archive caches message IDs for duplicates! Date: 07 Mar 1997 10:43:31 +0100 Sender: larsi@proletcult.slip.ifi.uio.no Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035150046 22538 80.91.224.250 (20 Oct 2002 21:40:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:40:46 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.5/8.8.5) with SMTP id CAA19768 for ; Fri, 7 Mar 1997 02:05:43 -0800 Original-Received: from proletcult.slip.ifi.uio.no (root@ppp11.larris.ifi.uio.no [129.240.68.111]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Fri, 7 Mar 1997 10:43:10 +0100 Original-Received: (from larsi@localhost) by proletcult.slip.ifi.uio.no (8.8.2/8.8.2) id KAA06316; Fri, 7 Mar 1997 10:43:42 +0100 Original-To: Steven L Baur In-Reply-To: Steven L Baur's message of 07 Mar 1997 01:26:37 -0800 Original-Lines: 49 X-Mailer: Gnus v5.4.22/Emacs 19.34 X-Face: &w!^oO~dS|}-P0~ge{$c!h\ writes: > So long as Message IDs are unique in a single Gnus group there is no > problem. The Gnus-Warning... lines are useful for weeding out garbage > in important lists on unreliable systems (like the Linux kernel > mailing list :-( ), but that is the minority case. They are also useful > for tagging mail sorted into my personal inbox that has been Cc'ed to > a mailing list. This last feature has been a little less reliable of > late because I did some fiddling and Gnus didn't put my inbox last in > order of incorporation of new mail for awhile. I don't dare blithely > drop mail for various reasons. > > If possible I'd like to keep the Gnus-Warning lines but have > duplicated messages thread properly. I've now implemented this -- nnmail no longer renames Message-ID on duplicate messages, and Gnus renames the Message-ID on duplicates in one "session" for threading purposes. That is, if you have two copies of the same message displayed in one summary buffer, one of these copies will thread properly, and the other won't. If you have just one copy, it will always thread properly, whether it's the original or the duplicate copy. There are two problems: If someone does the mail splitting with the new Gnus and the mail reading with an old Gnus, they will only see a single copy of the message in the summary buffer. (Which isn't nice, but is no big deal, I think.) The other is that if you have an nnvirtual group that has two component groups, which are really just the same group from different servers (this can be nice if there's some connectivity problems), things worked perfectly before, but people will see doubles now. This is rather obscure, though. That's all the negatives I can think of, so I think this'll work ok. > > The backends don't even have to know about this at all. Perhaps Gnus > > could just do an extra pre-processing pass over the headers to make > > sure all Message-ID's are unique? Or even better, Gnus could just > > (when it discovers that it has a Message-ID it has already read, it > > could just rename the Message-ID header on the fly? (This is all for > > internal threading purposes, so it shouldn't affect anything else...) > > Hm. > > That last thought sounds promising can you do it in 5.4? Gnus v5.4.22 -- this evening. -- If you want an explanation on what you have just read, please refer to .