From: Kevin Greiner <kgreiner@xpediantsolutions.com>
Subject: Re: Strange auto-caching
Date: Tue, 11 Feb 2003 01:07:39 -0600 [thread overview]
Message-ID: <ur8af70sk.fsf@xpediantsolutions.com> (raw)
In-Reply-To: <84hebdjx6q.fsf@lucy.is.informatik.uni-duisburg.de>
kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
> I have (add-hook 'gnus-select-article-hook
> 'gnus-agent-fetch-selected-article). Some articles have wrong %O
> status, even though they are shown. Look at this screenshot:
>
>
>
> Look at the articles marked "-R": I was reading them just some
> minutes ago, but selecting them didn't change %O from - to +.
>
> Look at the last two articles: when I entered the group they were
> marked as not downloaded, but reading them downloaded them and
> changed the "- " to "+R".
>
> I'd almost say that "." (new/unseen) marked articles get frobbed
> correctly. It's even true. But also there is the second line in the
> summary window: Ami's article got changed from "- " to "+R".
>
> It is all very confusing.
>
> Maybe it is useful to know that the internal data structures in Gnus
> are not corrupted: after reading all new downloaded articles in a group
> (changing "+ " to "+R" in the process), I can exit the group and then
> re-enter it and then the old downloaded articles change their marks
> from "- " to "+ "! So the old articles are shown okay when there are
> no new ones, but the presence of new ones screws things up for the
> old ones.
>
> In the previous paragraph, both new and old articles are unread and
> downloaded. New articles were downloaded in the same session (or
> perhaps by the last `g J s' invocation), whereas old articles were
> downloaded in a previous session. (I'm not sure if exit Emacs/start
> Emacs is what distinguishes old from new articles, or just another `g
> J s'.)
> --
> A turnip curses Elvis
Kai,
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.
Kevin
next prev parent reply other threads:[~2003-02-11 7:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-09 15:22 Kai Großjohann
2003-02-11 7:07 ` Kevin Greiner [this message]
2003-02-11 16:34 ` Kai Großjohann
2003-02-11 17:49 ` Kevin Greiner
2003-02-11 19:19 ` Kai Großjohann
2003-02-11 18:19 ` Kevin Greiner
2003-02-11 19:19 ` Kai Großjohann
2003-02-11 19:30 ` Kevin Greiner
2003-02-11 19:52 ` Kai Großjohann
2003-02-11 20:54 ` Kevin Greiner
2003-02-12 10:07 ` Kai Großjohann
2003-02-12 16:20 ` Kevin Greiner
2003-02-12 16:58 ` Kai Großjohann
2003-02-13 0:36 ` Kevin Greiner
2003-02-13 2:19 ` Kevin Greiner
2003-02-13 11:16 ` Kai Großjohann
2003-02-13 11:22 ` Kai Großjohann
2003-02-11 19:30 ` Kai Großjohann
2003-02-11 19:44 ` Kevin Greiner
2003-02-11 19:48 ` Kai Großjohann
2003-02-11 20:31 ` Danny Siu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ur8af70sk.fsf@xpediantsolutions.com \
--to=kgreiner@xpediantsolutions.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).