Re: Strange auto-caching

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> From what you are describing gnus-agent-fetch-selected-article updates
>> the internals correctly.  The problem has to be in its call to
>> gnus-summary-update-article-line.  I've already found, and I thought,
>> fixed a problem in this call.  There must be something else going
>> wrong.  Can you step through it to see what is happening?  What
>> happened before was that g-s-u-a-l jumped to, and updated, the wrong
>> line in the summary.
>
> My problem has nothing to do with gnus-summary-update-article-line.  I
> think...  I just did M-x edebug-defun RET on it, then entered a group
> and got this result (slightly massaged because of UTF-8 characters in
> thread trees):
>
> -   Thu 16.01., 19k: Robert J. Chass | Re: errors in Tramp FTP, yet file fetched
> -  +Sat 18.01.,3.7k: Kai Großjohann  | Todo: Forbidden word "path"
> -   Sun 19.01.,2.5k: Michael Albinus |  \-
> +Q  Jan 01 '70,0.0k:                 | Re: Preserve permissions after backup?
> -   Mon 27.01.,2.3k: Eli Zaretskii   | \-
> -   Mon 27.01.,2.0k: Richard Stallma |  \-
> +   Tue 28.01.,2.3k: Michael Albinus | Re: tramp (2.0.28); ange-ftp stopped working
> +   Tue 28.01.,3.0k: Michael Albinus | Re: Todo
>
> %O is the first char in each line.
>
> The function gnus-summary-update-article-line was not called.
>
> I verified that the `-' marked articles were also fetched by exiting
> the group, going unplugged, reentering the group, selecting Eli's or
> Richard's article.

The critical issue is, how did your fetch the articles?  Were they
fetched prior to opening the group, in the group using one of the
agent commands, or by using the gnus-agent-fetch-selected-article
method?

When you re-entered the group, were the %O fields identical to the sample above?

>
> Something else is also wrong in that `.' does not jump to `-' marked
> articles, only to `+' marked ones.  Maybe
> gnus-summary-first-unread-article and %O are accessing the same,
> wrong, data structure?

Well, I recently modified gnus-summary-first-subject to ignore the
'Undownloaded Article #' messages.
Testing... Nope. Works fine here.  I entered gnus.gnus-bug, pressed
'.' and jumped to the first unread message which happened to also be
marked as undownloaded ('-').

> Is there another function that I could trace through?

Well, let's see if we can get a little more info.

Edit your gnus-summary-line-format to display the article number (%N).

Open the group then move point to a line whose download indicator
appears to be incorrect. Do not attempt to select the article, just
put point on that line.

Execute M-: (gnus-summary-article-number)
  Note the number that is returned.  Does it match the article number
  displayed on that line?

Execute M-: (memq (gnus-summary-article-number) 
                  gnus-newsgroup-undownloaded)
  If it returns nil, the article has been downloaded and the indicator
  should be '+'.  Does the value returned by memq match the displayed
  indicator?

Execute M-: (let ((inhibit-read-only t)) 
             (upcase-region (progn (beginning-of-line) (point))
             (progn (end-of-line) (point))))
  This should have upper-cased the text of the article on the current
  line.

Execute M-: (gnus-summary-update-article-line 
             (gnus-summary-article-number)
             (gnus-summary-article-header (gnus-summary-article-number)))
  Did this restore the upper-cased article to its proper appearance?
  If it did not, upper case several articles then try the same update
  again.  Did the updated line display the correct indicator?

Open the article.
  Did gnus have to fetch it from the server?  Does this match your
  expectations knowning the value that (memq
  (gnus-summary-article-number) gnus-newsgroup-undownloaded) returned?
  (i.e. If the memq returned nil, gnus should NOT have had to fetch
  the article).

>
> Is anyone else seeing similar problems?

A number of people have reported similar problems.  In fact, we have a
couple of new threads right now that may be related.

Kevin