From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.help Subject: Re: Gnus: caching message headers? Date: Mon, 07 Sep 2020 10:37:00 -0700 Message-ID: <87v9gpqyir.fsf@ericabrahamsen.net> References: <874ko9sgcn.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="39683"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:9xR1/WMhIS77+P+fyQwNbTTb+kE= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 07 19:37:51 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 1kFL5T-000AFC-IO for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 07 Sep 2020 19:37:51 +0200 Original-Received: from localhost ([::1]:39992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFL5S-0002Uq-Kz for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 07 Sep 2020 13:37:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFL4x-0002Uj-23 for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 13:37:19 -0400 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:38512 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 1kFL4v-0007Ib-FO for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 13:37:18 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kFL4r-0009XR-U9 for help-gnu-emacs@gnu.org; Mon, 07 Sep 2020 19:37:13 +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:123984 Archived-At: 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. >> >> 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.