Moving & suppressing

Moving & suppressing

[Lars Magne Ingebrigtsen]

I have now written the code to move a .newsrc.eld from one server to
another, but it's probably horrendously slow.  Give it a whirl after
0.4 has been released.

I've also added support for suppressing duplicate articles.  This is
(kinda) poor man's, uhm, woperdaughter's, Xref support -- Gnus keeps a
list (and hashtb) of all Message-ID's that have been (marked as) read.
The next time Gnus sees a message with the same Message-ID, it will
mark it as read.  There's also an option for saving this list to a
file, but that's optional.

"See the manual for details."

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Moving & suppressing

[Greg Stark]

> I've also added support for suppressing duplicate articles.  This is
> (kinda) poor man's, uhm, woperdaughter's, Xref support -- Gnus keeps a
> list (and hashtb) of all Message-ID's that have been (marked as) read.
> The next time Gnus sees a message with the same Message-ID, it will
> mark it as read.  There's also an option for saving this list to a
> file, but that's optional.

While trying to evangalize a bit someone asked if Gnus could prevent them from
seeing the same e-mail message twice even if the message-id's weren't
available. 

This would be possible if we hashed the entire article, or even just the
length and the first block of the article and saved that as a kind of
pseudo-message-id. This really would be pretty nice, even i often see the same
mail message on multiple lists that i read via mail archives, and often these
archives don't retain the message-id's (i disagree with that as well of
course, but Gnus should be general enough to not assume all the backends are
news or mail. Some backends won't have any concept of message-id.)

This would be a moderately expensive operation, especially if we tried to do
it at summary buffer generation time, but it would be nicer if we tried to do
it just before showing an article, then if it was one we've already seen it
could magically become marked as a duplicate and we could go on to the next
article. That way we don't need to actually load the article until we would
have to anyways.

greg

Re: Moving & suppressing

[John Griffith]

>>>>> "GS" == Greg Stark <gsstark@MIT.EDU> writes:

    GS> While trying to evangalize a bit someone asked if Gnus could
    GS> prevent them from seeing the same e-mail message twice even if
    GS> the message-id's weren't available.

    GS> This would be possible if we hashed the entire article, or
    GS> even just the length and the first block of the article and
    GS> saved that as a kind of pseudo-message-id. This really would
    GS> be pretty nice, even i often see the same mail message on
    GS> multiple lists that i read via mail archives, and often these
    GS> archives don't retain the message-id's (i disagree with that
    GS> as well of course, but Gnus should be general enough to not
    GS> assume all the backends are news or mail. Some backends won't
    GS> have any concept of message-id.)

I think this would be nice as well, but difficult.  One problem with
this is that some lists add other junk to the beginnings and ends of
such messages, like "Forwarded through the blah list", or at least
extra white space.  Leading white space could be ignored when hashing,
but the other junk would be more problematic.  Other times messages
are embbeded in some kind of digest, so the parts of the digest would
have to be compared.

Duplicate messages with dissimilar Message-IDs.

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "GS" == Greg Stark <gsstark@MIT.EDU> writes:

GS> While trying to evangalize a bit someone asked if Gnus could prevent
GS> them from seeing the same e-mail message twice even if the
GS> message-id's weren't available.

Not reliably.  See my diatribe on gnu.emacs.gnus on the topic.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMgII9p6VRH7BJMxHAQHlXgP/XhOCf1Rz4u/ms1e4JjHbB1ZTnto8Qrbe
qCkuWd8CVfr1kswGLolMBh5ayBpe+svKb33qmVwW6zDexGn03UVBGsHbnJV/dfKC
XipCENOzHpdbKVX/t/Q3TkTtMCfe6piaHL/vwGcUPXTpnCXhcUEpXpYjxUsEKvVx
5K+UasmBDqE=
=kIdp
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ Curiosity never killed anything, except
<ratinox@unilab.dfci.harvard.edu>   \ maybe a few hours. -A cat's guide to life
http://www.dfci.harvard.edu/         \