Re: Gnus: caching message headers?

[Eric Abrahamsen]

Gregory Heytings via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Hi Eric,
>
> Many thanks for your answer.
>
>>> I would like to have, in the *Summary*, a complete list of the
>>> emails contained in a folder when I hit RET on its label.  Each
>>> time I do this however, Gnus asks me how many articles I want to
>>> retrieve, and issues a "UID FETCH 1:N (UID RFC822.SIZE
>>> BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (...)])" IMAP command, which
>>> can take quite some time to complete when N is large.
>>>
>>> Is there a way to convince Gnus to cache the result of that command
>>> (without caching all emails), and to issue a command only for the
>>> new UIDs?  Caching the result of that command should not eat too
>>> much disk space.
>>
>> No, not at the moment. You can avoid the prompt by customizing the
>> value of `gnus-large-newsgroup', but it's still going to retrieve
>> all the headers for the group.
>>
>> There's currently no way around this, as Gnus only lets you have one
>> active Summary buffer at a time, which means all the old data is
>> dumped every time you switch groups. In the back of my head I have
>> some ideas for removing this restriction, but it will take a long
>> time to get there.
>>
>
> I'm clearly not an expert, but would it not be enough to save and
> retrieve the contents of nntp-server-buffer in
> nnimap-retrieve-headers?  Or are you thinking about a more generic
> solution that would work with all backends?

We could do something ad-hoc for nnimap, but yes I'm thinking of
something more generic. All the header data (what's used to create the
Summary display) is held in variables that are local to the Summary
buffer, so in principle there's no reason we couldn't just leave the
local data in place when we leave the buffer. There are plenty of
obstacles to making it work correctly, but in principle I don't see why not.