From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: wgreenhouse Newsgroups: gmane.emacs.help Subject: Re: Gnus: caching message headers? Date: Mon, 07 Sep 2020 13:49:49 -0400 Message-ID: References: <874ko9sgcn.fsf@ericabrahamsen.net> <87v9gpqyir.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18639"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:yBbB94LSffGVq7/l8WyOTIPjyuQ= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 07 19:50:25 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kFLHc-0004im-Ik for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 07 Sep 2020 19:50:24 +0200 Original-Received: from localhost ([::1]:34774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFLHb-0003tK-LM for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 07 Sep 2020 13:50:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFLHF-0003t6-0J for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 13:50:01 -0400 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:52818 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFLHD-0000TM-6y for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 13:50:00 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kFLHA-0004DT-3s for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 19:49:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/07 11:25:51 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:123985 Archived-At: Eric Abrahamsen writes: > Gregory Heytings via Users list for the GNU Emacs text editor > 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. [...] > 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. The `agent' functionality might help here, in that it (among other things) creates an on-disk cache of headers seen in a group handled by the agent, so that it only needs to download headers again for articles that have not been seen yet. See (info "(gnus) Agent as Cache") for more on this. --wgreenhouse