Gnus development mailing list
 help / color / mirror / Atom feed
* Re: Ack!  nnfolder+archive caches message IDs for duplicates!
       [not found]       ` <m2209st5ma.fsf@altair.xemacs.org>
@ 1997-03-07  9:43         ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; only message in thread
From: Lars Magne Ingebrigtsen @ 1997-03-07  9:43 UTC (permalink / raw)
  Cc: ding

Steven L Baur <steve@miranova.com> 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 <URL:http://www.ifi.uio.no/~larsi/zombie.html>.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1997-03-07  9:43 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <m2rahswi8c.fsf@altair.xemacs.org>
     [not found] ` <m27mjkz8s8.fsf@proletcult.slip.ifi.uio.no>
     [not found]   ` <m267z42qem.fsf@altair.xemacs.org>
     [not found]     ` <m2sp28b1jo.fsf@proletcult.slip.ifi.uio.no>
     [not found]       ` <m2209st5ma.fsf@altair.xemacs.org>
1997-03-07  9:43         ` Ack! nnfolder+archive caches message IDs for duplicates! Lars Magne Ingebrigtsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).