Gnus development mailing list
 help / color / mirror / Atom feed
From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
Cc: ding@ifi.uio.no
Subject: Re: Ack!  nnfolder+archive caches message IDs for duplicates!
Date: 07 Mar 1997 10:43:31 +0100	[thread overview]
Message-ID: <m2zpwg9gvw.fsf@proletcult.slip.ifi.uio.no> (raw)
In-Reply-To: Steven L Baur's message of 07 Mar 1997 01:26:37 -0800

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>.


           reply	other threads:[~1997-03-07  9:43 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <m2209st5ma.fsf@altair.xemacs.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2zpwg9gvw.fsf@proletcult.slip.ifi.uio.no \
    --to=larsi@ifi.uio.no \
    --cc=ding@ifi.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).