Showing Complete Active Threads

Showing Complete Active Threads

[Rolleston]

Such a simple thing this, but I'm struggling to find a way to do it:
I would like to see in the summary buffer the whole of each thread 
in which each new message appears. That includes any messages I've
already read in that thread. In other words, if a thread is active,
I want to see it all. If it's inactive, I want to see none of it.

I've tried (setq gnus-fetch-old-headers 1000), but it doesn't work,
even for small threads in which all the messages are very recent and 
are available. The message summary lines do not appear for messages
that have been read before. I can type A R to get parent headers, but 
it's tedious to do that for each new summary line within a thread, and, 
in any case, I'm not sure if it will reconstruct the whole thread, 
rather than just the line of ancestry up to the root.

Any help with this would be much appreciated,

Thanks,

R.

Re: Showing Complete Active Threads

[Tassilo Horn]

Rolleston <Nemo@nullsome.net> writes:

> I've tried (setq gnus-fetch-old-headers 1000), but it doesn't work,
> even for small threads in which all the messages are very recent and 
> are available. 

Try

        (setq gnus-fetch-old-headers 't)

,----
| If this variable is t, Gnus will attempt to grab the headers to the old
| articles, and thereby build complete threads.
`----

Regards,
Tassilo

Re: Showing Complete Active Threads

[Rolleston]

Tassilo wrote:
> Try
>
>       (setq gnus-fetch-old-headers 't)

Somewhat suboptimal, I'd say, as it seems to often try to receive every available header.

Why doesn't (setq gnus-fetch-old-headers 1000) work when there are not even 1000 headers
in a group? In the tests I've done - which are hardly exhaustive - it seems to have done
absolutely nothing at all.

Look, here's an example.

First, I mark your message as unread, giving this summary buffer:

    08 Mar 08:38 Re: Showing Complete Active Threads Tassilo Horn

I instruct gnus to fetch old headers:

  M-: (setq gnus-fetch-old-headers 1000)

There should be no problem here. All the messages in this thread
are in the set containing the last 1000 messages.

I leave the summary buffer:

       1: gnu.emacs.gnus
     132: alt.test
       5: nndraft:drafts

So far so good :) Now I check for new messages (perhaps not necessaray to do that) and
hit <RET> to reenter the summar buffer. And this is what I see:

    08 Mar 08:38 Re: Showing Complete Active Threads Tassilo Horn

Oh... it's a loose thread. What happens if I type A R? Let's see now:

  R 08 Mar 06:07 Showing Complete Active Threads Rolleston
    08 Mar 08:38 \->  Tassilo Horn

And there it is, the whole thread. Hmm.. Ok. Let's try your suggestion (without the quote):

  M-u
  M-: (setq gnus-fetch-old-headers t)

We leap out of the summary buffer, and dive back in again:

  O 08 Mar 06:07 Showing Complete Active Threads Rolleston
    08 Mar 08:38 \->  Tassilo Horn

Hmmph! What's going on here?

Thanks,

R.

Re: Showing Complete Active Threads

[Tassilo Horn]

Rolleston <Nemo@nullsome.net> writes:

> Somewhat suboptimal, I'd say, as it seems to often try to receive
> every available header.

Sorry, I cannot follow you here. What do you mean with that it often
tries to receive every available header?

> I instruct gnus to fetch old headers:
>
>   M-: (setq gnus-fetch-old-headers 1000)
>
> [snip]
>
> So far so good :) Now I check for new messages (perhaps not necessaray
> to do that) and hit <RET> to reenter the summar buffer. And this is
> what I see:
>
>     08 Mar 08:38 Re: Showing Complete Active Threads Tassilo Horn

Hm, ok. Here I would expect the parent (your opening question), too.

> Oh... it's a loose thread. What happens if I type A R? Let's see now:
>
>   R 08 Mar 06:07 Showing Complete Active Threads Rolleston
>     08 Mar 08:38 \->  Tassilo Horn
>
> And there it is, the whole thread. Hmm.. Ok. Let's try your suggestion
> (without the quote):
   ^^^^^^^^^^^^^^^^^

Sure. ;-)

>   M-u
>   M-: (setq gnus-fetch-old-headers t)
>
> We leap out of the summary buffer, and dive back in again:
>
>   O 08 Mar 06:07 Showing Complete Active Threads Rolleston
>     08 Mar 08:38 \->  Tassilo Horn
>
> Hmmph! What's going on here?

Isn't that the behaviour you were looking for?

BTW: I use

     (setq gnus-fetch-old-headers 'some)

which fetches only those old headers needed to prevent loose threads
(all old headers till a common parent article is found). That's more
concise and expresses this thread's structure as well.

Regards,
Tassilo

Re: Showing Complete Active Threads

[Rolleston]

Tassilo Horn <heimdall@uni-koblenz.de> writes:

> Rolleston <Nemo@nullsome.net> writes:
>
>> Somewhat suboptimal, I'd say, as it seems to often try to receive
>> every available header.
>
> Sorry, I cannot follow you here. What do you mean with that it often
> tries to receive every available header?

It attempts to download every header it can from the news server. Try that
on 'alt.test' and you'll begin to see why (setq gnus-fetch-old-headers t)
is a bad idea. :) 

>>   M-u
>>   M-: (setq gnus-fetch-old-headers t)
>>
>> We leap out of the summary buffer, and dive back in again:
>>
>>   O 08 Mar 06:07 Showing Complete Active Threads Rolleston
>>     08 Mar 08:38 \->  Tassilo Horn
>>
>> Hmmph! What's going on here?
>
> Isn't that the behaviour you were looking for?

Well, yes, but without downloading every header (in some cases). Of course,
using a value of 1000 rather than, say, t, will mean that some old threads
may be loose, but most of the recent ones should be fine.

> BTW: I use
>
>      (setq gnus-fetch-old-headers 'some)
>
> which fetches only those old headers needed to prevent loose threads
> (all old headers till a common parent article is found). That's more
> concise and expresses this thread's structure as well.

Sounds good. If only it worked! :) 

Let's try it:

  08 Mar 19:43 Re: Showing Complete Active Threads Tassilo Horn

Once again, just the header for the last article in the thread. 

I've beenrummaging around in Google Groups again, and found this:

http://tinyurl.com/lects

I'm beginning to wonder if the gnus-fetch-old-headers option is fundamentally
broken, and has been so for years.

Ok, how about another approach?

Perhaps I could just download, say, the most recent 200 headers each time a group 
is entered, scoring the active threads in such a way that they are most prominent. 

I think scores will help here, but I'm not completely sure. There's quite a bit 
about scores in the manual, but I can't seem to find a section that describes how 
scores are used or why they are important. It would be rather strange to go to so 
much trouble talking about scores without saying what they can be used for, so 
perhaps I'm missing something completely obvious amongst the 457 manual pages.

Am I?

Your help is much appreciated. Thanks again,

R.

Re: Showing Complete Active Threads

[Tassilo Horn]

Rolleston <Nemo@nullsome.net> writes:

> It attempts to download every header it can from the news server. Try
> that on 'alt.test' and you'll begin to see why (setq
> gnus-fetch-old-headers t) is a bad idea. :)

Sometimes I was wondering why Gnus downloads several MBs when the group
only has a few new articles, too.

>> BTW: I use
>>
>>      (setq gnus-fetch-old-headers 'some)
>>
>> which fetches only those old headers needed to prevent loose threads
>> (all old headers till a common parent article is found). That's more
>> concise and expresses this thread's structure as well.
>
> Sounds good. If only it worked! :) 

At least it seems to work here with a fresh CVS Gnus.

> Ok, how about another approach?

Sorry, but that's too advanced for me. First I would try to check if
it's a real bug. Perhaps try setting

     (setq nntp-record-commands t)

which sends nntp-commands to Buffer *nntp-log*. Then you can see which
articles it fetches and see if it acts correctly. Helping to fix a bug
(if it really is one) is much better than working arround it.

Best regards,
Tassilo

Re: Showing Complete Active Threads

[Rolleston]

Tassilo Horn <heimdall@uni-koblenz.de> writes:

Correction: "gnus-thread-sort-by-most-recent-date"

R.

Gnus fetches too many headers WAS: Re: Showing Complete Active Threads

[Tassilo Horn]

Rolleston <Nemo@nullsome.net> writes:

> It attempts to download every header it can from the news server. Try that
> on 'alt.test' and you'll begin to see why (setq gnus-fetch-old-headers t)
> is a bad idea. :)

Ok, I was able to reproduce this. I've set nntp-record-commands to t and
made `g' in Summary Buffer to fetch new articles which resulted in

     infko.general (3)

When I entered this Group Gnus started to fetch several megabytes and
the output in *nntp-log* was

,----[ *nntp-log* after entering infko.general with 3 new articles ]
| 20060309T121041.752 news.uni-koblenz.de GROUP infko.general
| 20060309T121041.926 news.uni-koblenz.de XOVER 1-61172
`----

This newsgroup has medium traffic and I enter it several times a day, so
all except the 3 new articles should have been available...

After the `g' I also had

      comp.emacs (1)

and entering this group resulted in

,----[ *nntp-log* after entering comp.emacs with 1 new article ]
| 20060309T121028.368 news.uni-koblenz.de GROUP comp.emacs
| 20060309T121028.372 news.uni-koblenz.de XOVER 54834-54834
`----

That looks quite ok to me.

So why does Gnus fetch all headers of infko.general but only the needed
headers for comp.emacs?

INFO: I use Gnus with gnus-agent and try to prevent loose threads with

        (setq gnus-fetch-old-headers 'some)

      But the 3 new articles in infko.general don't reference old
      articles which would require the fetching of all headers.

Regards,
Tassilo

Re: Gnus fetches too many headers WAS: Re: Showing Complete Active Threads

[Dale Worley]

Tassilo Horn <heimdall@uni-koblenz.de> writes:
> When I entered this Group Gnus started to fetch several megabytes and
> the output in *nntp-log* was
> 
> ,----[ *nntp-log* after entering infko.general with 3 new articles ]
> | 20060309T121041.752 news.uni-koblenz.de GROUP infko.general
> | 20060309T121041.926 news.uni-koblenz.de XOVER 1-61172
> `----
> 
> This newsgroup has medium traffic and I enter it several times a day, so
> all except the 3 new articles should have been available...
> 
> After the `g' I also had
> 
>       comp.emacs (1)
> 
> and entering this group resulted in
> 
> ,----[ *nntp-log* after entering comp.emacs with 1 new article ]
> | 20060309T121028.368 news.uni-koblenz.de GROUP comp.emacs
> | 20060309T121028.372 news.uni-koblenz.de XOVER 54834-54834
> `----
> 
> That looks quite ok to me.
> 
> So why does Gnus fetch all headers of infko.general but only the needed
> headers for comp.emacs?

I've had some problems like this myself.  I think the problem is that
your .newsrc doesn't record all the numbers from 1 to 61172 as being
already seen, and so Gnus attempts to fetch every header in the range
with a separate HEAD command.  It is possible that the news server is
not reporting the "minimum article number present" correctly, and so
Gnus is attempting to fetch articles starting with number 1.  I would
log in to the NNTP server using telnet and do a "GROUP infko.general"
and see what the results are.  You may want to manually edit .newsrc
to say "infko.general: 1-60000" or something like that.  At the least,
if you tell Gnus to only fetch 100 articles from the group (when it
asks), it should run correctly.

Dale

Dale Worley						worley@theworld.com
--
The sky is falling; damage estimate to follow.	-- "The West Wing"

Re: Gnus fetches too many headers WAS: Re: Showing Complete Active Threads

[Tassilo Horn]

Dale Worley <worley@dragon.ariadne.com> writes:

Hi Dale,

> I've had some problems like this myself.  I think the problem is that
> your .newsrc doesn't record all the numbers from 1 to 61172 as being
> already seen, and so Gnus attempts to fetch every header in the range
> with a separate HEAD command.

My .newsrs has this entry:

,----
| infko.general: 1-63217
`----

Looks ok, doesn't it?

> It is possible that the news server is not reporting the "minimum
> article number present" correctly, and so Gnus is attempting to fetch
> articles starting with number 1. I would log in to the NNTP server
> using telnet and do a "GROUP infko.general" and see what the results
> are.

As I am no NNTP expert, how do I login and authenticate? The group is
only readable by students and employees of the university. Providing -l
<myuser> to telnet doesn't work.

> You may want to manually edit .newsrc to say "infko.general: 1-60000"
> or something like that.  At the least, if you tell Gnus to only fetch
> 100 articles from the group (when it asks), it should run correctly.

Normally it doesn't ask, because the group only has a handful new
articles. I suspect

,----
| gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
| Its value is some
`----

to cause the heavy loading of already seen articles, but I may be wrong.

Luckily this really happens only in some very rare cases and my internet
connection is fast enough to fetch some megs then.

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Gnus fetches too many headers WAS: Re: Showing Complete Active Threads

[Frank Schmitt]

Tassilo Horn <heimdall@uni-koblenz.de> writes:

> As I am no NNTP expert, how do I login and authenticate? The group is
> only readable by students and employees of the university. Providing -l
> <myuser> to telnet doesn't work.

[~]$ telnet newshost.uni-koblenz.de nntp
Trying 141.26.64.5...
Connected to newshost.uni-koblenz.de (141.26.64.5).
Escape character is '^]'.
200 cache.uni-koblenz.de InterNetNews NNRP server INN 2.4.2 ready (posting ok).
authinfo user fschmitt
381 PASS required
authinfo pass *******
281 Ok
group infko.general
211 59666 3 63244 infko.general

HTH, Frank

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Gnus fetches too many headers WAS: Re: Showing Complete Active Threads

[Tassilo Horn]

Tassilo Horn <heimdall@uni-koblenz.de> writes:

>> It is possible that the news server is not reporting the "minimum
>> article number present" correctly, and so Gnus is attempting to fetch
>> articles starting with number 1. I would log in to the NNTP server
>> using telnet and do a "GROUP infko.general" and see what the results
>> are.

By courtesy of Frank, I finally got it.

,----[ telnet ]
| GROUP infko.general
| 211 59666 3 63244 infko.general
`----

According to the RFC this looks plausible to me.

,----[ RFC977 3.2.1.  GROUP ]
| 3.2.2.  Responses
| 
|    211 n f l s group selected
|            (n = estimated number of articles in group,
|            f = first article number in the group,
|            l = last article number in the group,
|            s = name of the group.)
|    411 no such news group
`----

Bye,
Tassilo
-- 
A morning without coffee is like something without something else.

Re: Showing Complete Active Threads

[Matt Ford]

Hi,

I was having trouble with this too.  The following post describes the behaviour of the 'some and 't options and explains a lot.

http://groups.google.co.uk/group/gnu.emacs.gnus/browse_thread/thread/7c3cc8b63a45514c/4481cd0a00002013?lnk=st&q=gnus-fetch-old-headers&rnum=7&hl=en#4481cd0a00002013

A point to note is that (IMHO) A T will only show the complete thread of an article up to the post is was executed over (this caused me a lot of confusion when testing as I'd made assumptions about the A T command).  To test I ticked the original post in this thread and exited and came back into the group - hitting A T does nothing.  Marking any subsequent post in the thread and hitting A T gets all posts it knows about up until that point (the current last post will show you everything).

It could be argued that as "I KNOW" that the top level post has replies and I've marked them as read then hittting A T (or some other command) should redisplay them.  Whether this is implementable I don't know...certainly I'd like that behaviour.

Matt.

Re: Showing Complete Active Threads

[Matt Ford]

I've noticed a small exception: if you do A T on the head of a thread then it will return the complete thread up until another ticked or dormant article in the same thread.  This makes me think that caching might somehow help - assuming that's what ticking or making dormant somehow does (way out of my comfort zone here though).