gnus-summary-refer-parent-article weirdness

gnus-summary-refer-parent-article weirdness

[Paul Jarc]

I'm running current CVS oGnus, and getting some hard-to-pin-down
errors with gnus-summary-refer-parent-article.  When I try to get the
parent of an article, I sometimes get one of a variety of errors if
the parent is not already visible in the Summary buffer, but the
parent's parent is.  Sometimes the grandparent's Summary line gets
duplicated; sometimes the parent is inaccessible.  I can reproduce the
same error consistently in any case where it happens, but I can't
figure out what makes those cases different from cases where no error
occurs.

Example: <URL:http://multivac.cwru.edu/prj/log.tar.gz> is a maildir
with 3 messages, each a reply to the last.  If the first and third are
'ticked (thus visible) and the second is 'read (thus not initially
visible), I get an error if I '^' on the third article.  'C-u RET' to
enter the group shows the correct thread structure.

Some of my Gnus-related configuration stuff can be found at
<URL:http://multivac.cwru.edu/prj/gnus>.  This is all from my .emacs;
I have no .gnus.

" *nntpd*" seems to contain correct data the whole time, so I don't
think this is a backend problem, but in case it is, you can get
nnmaildir from <URL:http://multivac.cwru.edu/nnmaildir/>.

This problem, or one like it, existed at least as far back as 5.8.7,
although for the particular instance where I found and could reproduce
the error in 5.8.7, oGnus did not exhibit the error.  I think 5.8.8
also fixed that particular case.


paul

Re: gnus-summary-refer-parent-article weirdness

[Paul Jarc]

I wrote:
> When I try to get the parent of an article, I sometimes get one of a
> variety of errors if the parent is not already visible in the
> Summary buffer, but the parent's parent is.  Sometimes the
> grandparent's Summary line gets duplicated; sometimes the parent is
> inaccessible.  I can reproduce the same error consistently in any
> case where it happens, but I can't figure out what makes those cases
> different from cases where no error occurs.

I think I've figured it out, partly.  I entered nntp:gnu.emacs.gnus
and marked these three articles like this:
! *    21 ]: Seth Delackner       Re: Close, but not complete, POP3...
R *    47   ]: Garglemonster
! *    27     ]: Seth Delackner

Then I left the group and re-entered.  At this point, the " *nntpd*"
buffer contains NOV lines for all three articles:
59976	Re: Close, but not complete, POP3 solutions for gnus	Seth Delackner <seth@jtan.com>	Fri, 22 Mar 2002 22:05:10 GMT	<bsdgfecz.fsf@jtan.com>	<vgc8l2cm.fsf@bitstream.com> <m21yepijpn.fsf@vador.mandrakesoft.com>	2037	21	Xref: usenet.INS.cwru.edu gnu.emacs.gnus:59976
59980	Re: Close, but not complete, POP3 solutions for gnus	Garglemonster <garglemonster@my-deja.com>	23 Mar 2002 10:58:45 +0900	<wmpr8mcvycq.fsf@nefastis.disorg>	<vgc8l2cm.fsf@bitstream.com> <m21yepijpn.fsf@vador.mandrakesoft.com> <bsdgfecz.fsf@jtan.com>	2517	47	Xref: usenet.INS.cwru.edu gnu.emacs.gnus:59980
59982	Re: Close, but not complete, POP3 solutions for gnus	Seth Delackner <seth@jtan.com>	Sat, 23 Mar 2002 07:01:46 GMT	<r8mb938u.fsf@jtan.com>	<vgc8l2cm.fsf@bitstream.com> <m21yepijpn.fsf@vador.mandrakesoft.com> <bsdgfecz.fsf@jtan.com> <wmpr8mcvycq.fsf@nefastis.disorg>	2467	27	Xref: usenet.INS.cwru.edu gnu.emacs.gnus:59982

Even though debug-on-entry shows that the middle article's number was
not passed to nntp-retrieve-headers:
* nntp-retrieve-headers((59893 59908 59909 59910 59911 59913 59914 59915 59916 59918 59923 59927 59930 59931 59932 59934 59936 59937 59938 59939 59940 59941 59942 59944 59945 59951 59954 59955 59956 59957 59962 59963 59964 59966 59968 59969 59972 59974 59975 59976 59978 59979 59981 59982 59983 59984 59985 59986 59987 59988 ... . (59989 59990 59991 59992 59996 59998 60004 60005 60007 60008)) "gnu.emacs.gnus" "" nil)

Typing "^" on the second article from Seth fetches the right article,
but only because nntp provided information beyond what was requested.
In a similar experiment with an nnmaildir group, the middle article's
NOV line is *not* included in " *nntpd*":

! *    10 ]: Lars Magne Ingebrigt Quimby problems
E *     6   ]: Florian Weimer
! *    10     ]: Lars Magne Ingebrigt

126	Quimby problems	Lars Magne Ingebrigtsen <larsi@gnus.org>	Sat, 23 Mar 2002 10:29:57 +0100	<m3n0wz1vje.fsf@quimbies.gnus.org>		2536	10	Xref: nnmaildir ding:126	
128	Re: Quimby problems	Lars Magne Ingebrigtsen <larsi@gnus.org>	Sat, 23 Mar 2002 10:49:38 +0100	<m3it7n1uml.fsf@quimbies.gnus.org>	<m3n0wz1vje.fsf@quimbies.gnus.org> <87663nbouv.fsf@deneb.enyo.de>	2469	10	Xref: nnmaildir ding:128	

Simply because nnmaildir wasn't asked for that information; 127 (the
middle article's number) does not appear here:
* nnmaildir-retrieve-headers((1 2 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 33 35 36 37 39 40 41 42 43 44 45 46 48 49 50 51 52 53 54 55 ... . (56 57 58 59 60 126 128 134 142)) "ding" "" nil)

So:
0. How does nntp know to provide extra information?  Is nntp.el doing
   this, or is it my news server?
1. Should Gnus rely on this?  Or should it refrain from assuming that
   all real articles of interest will have been listed by
   -retrieve-headers?


paul