Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: How about gnus-registry-precious-only-p?
Date: Wed, 20 May 2020 12:47:25 -0700	[thread overview]
Message-ID: <87blmifkxe.fsf@ericabrahamsen.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: registry-precious-only.diff --]
[-- Type: text/x-patch, Size: 1282 bytes --]

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)))

             reply	other threads:[~2020-05-20 19:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 19:47 Eric Abrahamsen [this message]
2020-06-09 16:15 ` Ted Zlatanov
2020-06-12 16:04   ` Eric Abrahamsen
2020-06-16 17:08     ` Ted Zlatanov
2020-06-16 18:29       ` Eric Abrahamsen
2020-06-16 19:08         ` Ted Zlatanov
2020-06-16 21:46           ` Eric Abrahamsen
2020-06-12 14:46 ` Bob Newell

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=87blmifkxe.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=ding@gnus.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).