help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnus: caching message headers?


From: Eric Abrahamsen
Subject: Re: Gnus: caching message headers?
Date: Sat, 12 Sep 2020 16:29:39 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Ozhap <ozhap@vollbio.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Ozhap <ozhap@vollbio.de> writes:
>>
>>>>> “If I read an article while plugged, do they get entered into the 
>>>>> Agent?”
>>>>>
>>>>> *No*.  If you want this behavior, add 
>>>>> ‘gnus-agent-fetch-selected-article’ to ‘gnus-select-article-hook’.
>>>
>>>> That Info page could be more explicit that `gnus-agent-cache' means that
>>>> articles *will* be added to the agent as they are read.
>>>
>>> That's how it stands now, but in info '(gnus)Agent as Cache' it says:
>>>
>>> "..Gnus normally only downloads *headers* once, and stores them in the
>>> Agent"
>>>
>>> "Articles are *not* cached in the Agent by default though (that would
>>> potentially consume lots of disk space), but if you have *already
>>> downloaded an article into the Agent*, Gnus will not download the
>>> article from the server again but use the locally stored copy instead."
>>>
>>> I did some digging, and this behaviour was changed due to bug#8502 where
>>> Lars concludes (erroneously, on the face of it):
>>>
>>>> Let's see...  caching...  so if you're online (in an agentised group)
>>>> and select an article, you want the article to be saved in the Agent
>>>> directory?  That sounds eminently reasonable, and I thought that was
>>>> supposed to happen, but I can't find any code for doing that...  hm...
>>>> Nope.
>>>
>>> Ref:
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8502
>>
>> If I were you I would do this up as a proper bug report. Lars is now an
>> Emacs maintainer, so he'll be obliged to look at it :)
>>
>> One way or another there is a mismatch between documentation,
>> customization options, and actual observed behavior. I think if you can
>> make it clear what that mismatch is, we stand a good chance of getting
>> it fixed.
>
> Here you go. I think I did good :)
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43356

I saw it, I agree it's good!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]