all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: help-gnu-emacs@gnu.org
Subject: Re: Gnus: caching message headers?
Date: Mon, 07 Sep 2020 10:37:00 -0700	[thread overview]
Message-ID: <87v9gpqyir.fsf@ericabrahamsen.net> (raw)
In-Reply-To: alpine.NEB.2.22.394.2009071901130453.1423@sdf.lonestar.org

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.




  reply	other threads:[~2020-09-07 17:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 15:23 Gnus: caching message headers? Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-07 16:26 ` Eric Abrahamsen
2020-09-07 17:10   ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-07 17:37     ` Eric Abrahamsen [this message]
2020-09-07 17:49       ` wgreenhouse
2020-09-08 13:19         ` Eric S Fraga
2020-09-08 13:37         ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-08 14:34           ` Stefan Monnier
2020-09-08 17:29             ` Eric Abrahamsen
2020-09-08 21:52             ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-08 22:33               ` Stefan Monnier
2020-09-08 16:12           ` wgreenhouse
2020-09-08 20:39             ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-07 17:50       ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-07 17:53         ` Eric Abrahamsen
2020-09-07 23:48   ` Multiple summary buffers (was: Gnus: caching message headers?) Tim Landscheidt
2020-09-08  0:22     ` Multiple summary buffers Eric Abrahamsen
  -- strict thread matches above, loose matches on Subject: below --
2020-09-10  8:38 Gnus: caching message headers? Ozhap
2020-09-10  9:00 ` Gregory Heytings via Users list for the GNU Emacs text editor
2020-09-10  9:34   ` Ozhap
2020-09-10  9:45     ` Ozhap
2020-09-10 13:16   ` wgreenhouse
2020-09-10 23:41 Ozhap
2020-09-11 22:59 ` Eric Abrahamsen
2020-09-12 23:08   ` Ozhap
2020-09-12 23:29     ` Eric Abrahamsen
2020-10-04  9:12       ` Madhu
2020-10-07 11:39 Ozhap
2020-10-08  1:59 Ozhap
2020-10-08  3:28 Ozhap

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=87v9gpqyir.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=help-gnu-emacs@gnu.org \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.