From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14537 invoked from network); 20 May 2020 19:48:33 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 20 May 2020 19:48:33 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92.3) (envelope-from ) id 1jbUh2-0008AK-UN; Wed, 20 May 2020 14:47:56 -0500 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jbUgy-00087S-5O for ding@lists.math.uh.edu; Wed, 20 May 2020 14:47:52 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jbUgw-00071L-Gd for ding@lists.math.uh.edu; Wed, 20 May 2020 14:47:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:Mime-Version:Message-ID:Date:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PfOYNKHVX/LFCw1iTMrpxdYDdPBym94E618cMYItxLI=; b=XNcKK+P+ALbShKr9O+CI2BF3oh iMY8eq1nRlU3iSwV6nOTlHO6AnNfiXy8pbqbw1AsnBa2HYTnCu/xjS2zTCXhwmX+e1v3khdNNp3c/ RYyWUUbIm4ViZWU6Pq1RYXFQ/UvgCHlhv3QY989UN0LpyU4eOOqq5vV1JQHDzl78/gVw=; Received: from ciao.gmane.io ([159.69.161.202]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbUgn-00063j-Fb for ding@gnus.org; Wed, 20 May 2020 21:47:46 +0200 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jbUgm-0001A0-6K for ding@gnus.org; Wed, 20 May 2020 21:47:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ding@gnus.org From: Eric Abrahamsen Subject: How about gnus-registry-precious-only-p? Date: Wed, 20 May 2020 12:47:25 -0700 Message-ID: <87blmifkxe.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:T+ARUFZWg+KqA2xaepkXk48SjFQ= List-ID: Precedence: bulk --=-=-= Content-Type: text/plain Hey all, It occurred to me that if you're not using the Gnus registry's split-with-parent functionality, there really isn't any need to let it bloat up with thousands of entries. If all you're doing with it is setting registry marks on messages (or using Gnorb's Gnus<->Org tracking, or message tagging), the only entries we ever need are those where we've explicitly added "precious" information to a message. The attached patch does that, I think (modulo stuff I haven't thought of). I called it `gnus-registry-precious-only-p' because I originally thought it would do some filtering on Summary exit or something like that, but it turned out to be simpler than that: all the commands I'm aware of that set precious information on an entry do so with a "get-or-create" lookup. Meaning that setting the information is enough to create the entry, meaning all we have to do is not create entries automatically. So this option is a tiny bit of a misnomer, but I still think it's appropriate because pruning will avoid precious entries, and the end effect is that the only entries you're left with are those with precious information. If you delete that information later, the entry will be eligible for pruning. Most people will have a relatively tiny number of precious entries, so if you're not using the registry for splitting this could save you a lot of space and save time. WDYT? [Gnorb-related addendum: I've never used registry split-with-parent, because it seemed like the potential for chaos was high. But if we only keep a very controlled number of entries in the registry, this could provide an alternate mechanism for creating groups that hold messages related to an Org heading. Gnorb can do that now with ephemeral groups, but these would be real mail groups: track the first message, move it to a group "about" an Org heading, and subsequent replies to that message will get moved as well. Hmm, could messages be copied instead of moved...?] Eric --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=registry-precious-only.diff diff --git a/lisp/gnus/gnus-registry.el b/lisp/gnus/gnus-registry.el index f306889a7f..72f5938944 100644 --- a/lisp/gnus/gnus-registry.el +++ b/lisp/gnus/gnus-registry.el @@ -234,6 +234,14 @@ gnus-registry-max-entries :type '(radio (const :format "Unlimited " nil) (integer :format "Maximum number: %v"))) +(defcustom gnus-registry-only-precious-p nil + "When non-nil, only save entries with a \"precious\" key. +Entries are still created when entering a Summary buffer, but +non-precious entries are deleted when exiting the buffer. See +`gnus-registry-extra-entries-precious' for the meaning of +\"precious\"." + :type 'boolean) + (defcustom gnus-registry-prune-factor 0.1 "When pruning, try to prune back to this factor less than the maximum size. @@ -839,7 +847,8 @@ gnus-registry-find-keywords (defun gnus-registry-register-message-ids () "Register the Message-ID of every article in the group." - (unless (gnus-parameter-registry-ignore gnus-newsgroup-name) + (unless (or (gnus-parameter-registry-ignore gnus-newsgroup-name) + gnus-registry-only-precious-p) (dolist (article gnus-newsgroup-articles) (let* ((id (gnus-registry-fetch-message-id-fast article)) (groups (gnus-registry-get-id-key id 'group))) --=-=-=--