Sparse threads

Sparse threads

[Lars Magne Ingebrigtsen]

I thought filling in "gaps" in threads (without reading further
headers) would be a) a major project and b) slow as hell, but it
turned out to be quite simple to do.  Just some References munging,
some sorting (since Message-IDs late in the References headers are
probably more reliable (with regards to what sequence articles have
been posted) than early Message-IDs), and some threading.  

Before:

---------------
   [  52: Egil Kvaleberg      ] Re: Redaktoransvar
       [  47: Erik Naggum         ] 
           [  25: Steinar Bang        ] 
       <  16: Gisle Hannemyr      > 
           [  14: Willy Verwoerd      ] 
---------------


After:

---------------
Q  [   0:                     ] Re: Redaktoransvar
       [  52: Egil Kvaleberg      ] 
           [  47: Erik Naggum         ] 
               [  25: Steinar Bang        ] 
Q      [   0:                     ] 
           [  16: Gisle Hannemyr      ] 
               [  14: Willy Verwoerd      ] 
---------------

The two articles that are marked with "Q" are the new "gaps" inserted
to fill out the thread.  They can't be selected.

On the other hand -- Gnus does know the Message-ID of the "gap"
articles, so it could just fire off a request-by-id command?  Yup, I
think I'll add that.

(14 features left on the todo list -- but they all require access to a
Real Computer to write, I think.  `open-network-stream', etc.  Curse
you, Windos '95!)

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: Sparse threads

[Per Abrahamsen]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

LMI> I thought filling in "gaps" in threads (without reading further
LMI> headers) would be a) a major project and b) slow as hell, but it
LMI> turned out to be quite simple to do.  Just some References munging,
LMI> some sorting (since Message-IDs late in the References headers are
LMI> probably more reliable (with regards to what sequence articles have
LMI> been posted) than early Message-IDs), and some threading.  

This is great, it has been one of my major wishes since Gnus 3.13!  I
have even attempted to implement it several times, but each time
concluded that it was too hard.  

I hope it works with the various values of `gnus-fetch-old-headers',
in particular (setq gnus-fetch-old-headers 'some) should give you all
the same articles as trn finds.

Re: Sparse threads

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I hope it works with the various values of `gnus-fetch-old-headers',
> in particular (setq gnus-fetch-old-headers 'some) should give you all
> the same articles as trn finds.

Yes, sparse threads should work very nicely with
`gnus-fetch-old-headers' set to `some', I think.  

Oh, I forgot to mention that there are three settings to
`gnus-build-sparse-threads' -- nil, t, and `total', which is kinda
like nil, `some' and t for `gnus-fetch-old-headers'.  Perhaps I should
use the same naming scheme for both variables?  Yes, I think so.  

I haven't road-tested it much, but these sparse threads seem quite
pleasing to me.  They do make many threads quite a lot deeper,
though. 

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: Sparse threads

[Greg Stark]

sparse threads are really cool, thanks a lot lars!
i have two questions though:

the scenario is; i'm reading a response to an article that i've already read
another response to some other day does it show me that other response?  
in other words, having already read articles 1 and 2 in the following thread, 
i am now looking at article 3:
  [1] - [2]
    \ - [3]
i believe with a setting of t (equivalent of 'some) it will show me [1] but
not [2], the old reply.  in other words, sparse threads will get me:
  [1] - [3]
i think it is relatively important to know that i've already seen a reply. 
i would like a way of seeing such a reply without necessarily asking for the
entire thread since the beginning of time; there are several newsgroups where
threads are starting to march off past the width of my screen (and I decrease
the indentation already).


the other scenario is in my mail groups. a lot of the mail in my mail box
consists of replies to mail i sent out.  the mail i sent out isn't in my mail
box of course, but it is (now) stored in the mail archive.  it would be nice
if gnus would check for any missing article msg-id's in the outgoing mail (and
maybe news) archive.  This would actually make sparse threads useful in mail
groups; currently all it does is make a lot of pieces of mail take two lines,
one of which is mostly content-free.


greg

Re: Sparse threads

[Lars Magne Ingebrigtsen]

gsstark@MIT.EDU (Greg Stark) writes:

> i am now looking at article 3:
>   [1] - [2]
>     \ - [3]
> i believe with a setting of t (equivalent of 'some) it will show me [1] but
> not [2], the old reply.  in other words, sparse threads will get me:
>   [1] - [3]
> i think it is relatively important to know that i've already seen a reply. 

September 0.30 allows a `more' value to `gnus-build-sparse-threads'
that won't cut off these leaf nodes.

> the other scenario is in my mail groups. a lot of the mail in my
> mail box consists of replies to mail i sent out.  the mail i sent
> out isn't in my mail box of course, but it is (now) stored in the
> mail archive.  it would be nice if gnus would check for any missing
> article msg-id's in the outgoing mail (and maybe news) archive.
> This would actually make sparse threads useful in mail groups;
> currently all it does is make a lot of pieces of mail take two
> lines, one of which is mostly content-free.

Uhm.  I don't think Gnus should go check the archive group; that would
take too long.  However, you will be able to select these sparse nodes
in the future, and that selection is done on Message-ID.  So you could
just set `gnus-refer-article-method' to the archive server in you mail
groups, and *presto*.  This'll fill out the line in the summary buffer
with the proper information, even.

-- 
Home is where the cat is.

Re: Sparse threads

[Greg Stark]

>>>>> Lars Magne Ingebrigtsen writes:
> Uhm.  I don't think Gnus should go check the archive group; that would take
> too long.  However, you will be able to select these sparse nodes

That sounds pretty cool.

Would this be more feasible if the archive method were a method that had an
overview file?  What advantages does nnfolder have?

greg

Re: Sparse threads

[d. hall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

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

ð thus on 20 Jan 1996 09:09:33 -0500, Greg virtually scripted...
>>>>>> Lars Magne Ingebrigtsen writes:

>> Uhm.  I don't think Gnus should go check the archive group; that would
>> take too long.  However, you will be able to select these sparse nodes

Greg> That sounds pretty cool.

Greg> Would this be more feasible if the archive method were a method that
Greg> had an overview file?  What advantages does nnfolder have?

if gnus-message-archive-method sets nnfolder-get-new-mail to nil, then the
default nnfolder-get-new-mail is set to nil.  this is annoying for me since
i use nnfolder to read my mail, and it took me the longest time to figure
out why gnus wasn't getting it from the spool.  gnus-message-archive-method
should be using localized variables, no?  i think it might be due to the
fact that i'm a minimalist, and i don't set varibles when their defaults
suffice, but in this case the default is being changed.

d.
- --
<<I'm sorry Mr. President.  I don't dance.>>
				~ from clear and present danger

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMQFnjoX26urqpgG1AQHtSgP8CJWCVxmmGWLrlFwD7YztE0Sh5kzDMx/6
vCq2KYUNzQJrHeCioVYM4EbsMORtHOiRs97M+EQX4WlktRCNX1hRgAFwILD4QN6i
rU13FsiZtPymUOMIBEX/HsZI28Q3GfPXqDdjDmwHzAUJfFxdjIbJc1TF3Eiafui4
F9VgqjCbXy8=
=nUQ1
-----END PGP SIGNATURE-----

Re: Sparse threads

[Lars Magne Ingebrigtsen]

gsstark@MIT.EDU (Greg Stark) writes:

> > Uhm.  I don't think Gnus should go check the archive group; that would take
> > too long.  However, you will be able to select these sparse nodes
> 
> That sounds pretty cool.
> 
> Would this be more feasible if the archive method were a method that had an
> overview file?  What advantages does nnfolder have?

The advantage of nnfolder is that it uses one mbox file per group,
which means that you can read these folder with just about any mail
reader.  The disadvantage is that these files can grow rather big,
which slows down just about everything.  nnfolder does not maintain an
overview file, and it wouldn't really help much if it did.

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

Re: Sparse threads

[Lars Magne Ingebrigtsen]

dhall@apk.net (d. hall) writes:

> if gnus-message-archive-method sets nnfolder-get-new-mail to nil, then the
> default nnfolder-get-new-mail is set to nil.  this is annoying for me since
> i use nnfolder to read my mail, and it took me the longest time to figure
> out why gnus wasn't getting it from the spool.  gnus-message-archive-method
> should be using localized variables, no? 

Yes, and it does -- as long as the name of the server is different
from the name of your other nnfolder servers.  Which is why it was
called "archive".

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