From: cliff@sfn.ORG (R. Cliff Young)
Subject: Re: Does gnus 3.14 thread better than 3.13?
Organization: Society for Neuroscience
Distribution: gnu
Date: Wed, 2 Sep 1992 15:50:44 GMT

In article <JONATHAN.92Sep1222653@speedy.cs.pitt.edu> jonathan@cs.pitt.edu (Jonathan Eunice) writes:
>I'm using gnus 3.13.  It seems to thread articles based on the References
>field, ignoring the subject line contents. For example, it gives me
>multiple lines: 
>
>D 890:+[ 48:bradm@anchor.] Re: changing indentation thingees
>  891: [  7:diecph@ucunix] Re: changing indentation thingees
>
>which should be a part of just one thread, based on the Subject:
>
>D 890:+[ 48:bradm@anchor.] Re: changing indentation thingees...
>
>Would using 3.14 improve this behavior?  

No, 3.14 exhibits the same behavior.  The underlying problem is that
only articles in the Subject buffer are available for GNUS to figure
out the thread structure.  Unless you specifically instruct GNUS to
retrieve all available articles (using a prefix argument to either SPC
or = when selecting a newsgroup), it can only thread based on the
relationships between the unread articles that are retrieved by
default.  Thus, in your example, both articles 890 and 891 may very
well be well-formed followups to article 847, but since article 847
was an old, read message, it is not among the unread messages that
have been made available for thread-processing in the subject buffer.

I imagine GNUS' threading is rather simplistic because of its original
or primary design as an NNTP news client running under Emacs.  Unlike
trn, it does not maintain a threading database, so it must always
thread based on what article headers it requests from the NNTP server.
It would be too unwieldy (I imagine--I currently use news on a local
spool) to have GNUS request the headers for all available articles
every time you enter a newsgroup just so that it could construct a
"proper" thread tree.

An artifact of this simplistic threading is that, if you read certain
newgroups consistently and often, you will rarely see thread trees or
subtrees under GNUS.

If GNUS were to achieve a level of threading sophistication equivalent
to trn, it would need to do the following (based upon my personal
observations of trn in action):

1) Maintain a threading database.  This would allow GNUS to display a
   full thread tree without necessitating that older articles be
   accessed as well as newer, unread articles.  Access to the older
   articles will be accomplished in much the same fashion as access to
   a parent article with the "^" command.

2) Ignore subject changes when threading.  Currently you can configure
   GNUS to do this by assigning the variable
   gnus-thread-ignore-subject a non-nil value.  However, the GNUS
   manual mentions that "If [gnus-thread-ignore-subject] is non-nil
   and thread subtrees are hidden, some commands work [sic] with
   subjects may not work properly."

   Threads relationships would thus be based solely on the References
   header.  This permits a user to easily track some threads through
   the myriad levels of subject changes they sometimes seem to
   undergo.

3) Some broken news-posting software or indirect methods of
   following-up to a posting fail to include a valid References
   header.  So long as these postings contain a subject line matching
   a subject in an existing thread, they should be considered a part
   of that thread, albeit at a new level (i.e. no parent).  Currently,
   you can get this behavior in GNUS by sorting your Subject buffer by
   subject.

4) However, an article without a valid References header but containing
   a valid Message-ID in the initial text of the message ("In article
   <msg-id> so-and-so writes:", et al) should treat the message with
   that Message-ID as its parent for threading purposes.  This would
   be a more difficult behavior of trn to implement in GNUS, as it
   would require the body of a message to be retrieved.  Probably not
   worth it unless you're reading from a local spool.

I consider GNUS threading to be at its most useful when you're reading
articles after a long hiatus, or when you tell GNUS to retrieve all
articles of a newsgroup.  Implementation of some sort of threading
database or history will bring it up more on a par with trn.

Apologies for rambling so... !

--
 R. Cliff Young, SysAdmin, SFN --/\/-- cliff@sfn.ORG