[-- 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)))
On Wed, 20 May 2020 12:47:25 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: EA> It occurred to me that if you're not using the Gnus registry's EA> split-with-parent functionality, there really isn't any need to let it EA> bloat up with thousands of entries. If all you're doing with it is EA> setting registry marks on messages (or using Gnorb's Gnus<->Org EA> tracking, or message tagging), the only entries we ever need are those EA> where we've explicitly added "precious" information to a message. I agree, and think that it should be t by default (keep only precious entries). I would go further and never record non-precious messages on exiting the group, to avoid the extra cycles. EA> [Gnorb-related addendum: I've never used registry split-with-parent, EA> because it seemed like the potential for chaos was high. But if we only EA> keep a very controlled number of entries in the registry, this could EA> provide an alternate mechanism for creating groups that hold messages EA> related to an Org heading. Gnorb can do that now with ephemeral groups, EA> but these would be real mail groups: track the first message, move it to EA> a group "about" an Org heading, and subsequent replies to that message EA> will get moved as well. Hmm, could messages be copied instead of EA> moved...?] I have seen no interest in this, so it's your call whether there are enough users to justify the effort. -- Ted Zlatanov <tzz@lifelogs.com>
> 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.
I must agree! For months and months I fought registry bloat
with little luck. Eventually some patches and fixes came in
(thank you Eric!) but it still was more than I wanted.
So I went to a system such as what Eric has suggested. Now the
registry has a small handful of entries that really matter and
it actually serves a useful purpose.
--
Bob Newell
Honolulu, Hawai`i
- Via GNU/Linux/Emacs/Gnus/BBDB
Bob Newell <bobnewell@bobnewell.net> writes: >> 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. > > I must agree! For months and months I fought registry bloat > with little luck. Eventually some patches and fixes came in > (thank you Eric!) but it still was more than I wanted. > > So I went to a system such as what Eric has suggested. Now the > registry has a small handful of entries that really matter and > it actually serves a useful purpose. Okay, that's good enough for me! Ted Zlatanov <tzz@lifelogs.com> writes: > On Wed, 20 May 2020 12:47:25 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > > EA> It occurred to me that if you're not using the Gnus registry's > EA> split-with-parent functionality, there really isn't any need to let it > EA> bloat up with thousands of entries. If all you're doing with it is > EA> setting registry marks on messages (or using Gnorb's Gnus<->Org > EA> tracking, or message tagging), the only entries we ever need are those > EA> where we've explicitly added "precious" information to a message. > > I agree, and think that it should be t by default (keep only precious > entries). > > I would go further and never record non-precious messages on exiting the > group, to avoid the extra cycles. I might be misunderstanding, but with the up-thread patch, non-precious messages shouldn't be made in the first place. The only way (Which reminds me, now is the right time to come up with a better name for this option. Maybe `gnus-registry-auto-create-entries', defaulted to nil?) > EA> [Gnorb-related addendum: I've never used registry split-with-parent, > EA> because it seemed like the potential for chaos was high. But if we only > EA> keep a very controlled number of entries in the registry, this could > EA> provide an alternate mechanism for creating groups that hold messages > EA> related to an Org heading. Gnorb can do that now with ephemeral groups, > EA> but these would be real mail groups: track the first message, move it to > EA> a group "about" an Org heading, and subsequent replies to that message > EA> will get moved as well. Hmm, could messages be copied instead of > EA> moved...?] > > I have seen no interest in this, so it's your call whether there are > enough users to justify the effort. Well there's one, at least! Maybe that's enough.
On Fri, 12 Jun 2020 09:04:36 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
EA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I would go further and never record non-precious messages on exiting the
>> group, to avoid the extra cycles.
EA> I might be misunderstanding, but with the up-thread patch, non-precious
EA> messages shouldn't be made in the first place. The only way
I misread the patch. Apologies. Looks great to me.
EA> (Which reminds me, now is the right time to come up with a better name
EA> for this option. Maybe `gnus-registry-auto-create-entries', defaulted to
EA> nil?)
Yes, I'd be OK with that. Users may have customized
`gnus-registry-extra-entries-precious' but I think it's unlikely.
--
Ted Zlatanov <tzz@lifelogs.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Fri, 12 Jun 2020 09:04:36 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> EA> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I would go further and never record non-precious messages on exiting the
>>> group, to avoid the extra cycles.
>
> EA> I might be misunderstanding, but with the up-thread patch, non-precious
> EA> messages shouldn't be made in the first place. The only way
>
> I misread the patch. Apologies. Looks great to me.
>
> EA> (Which reminds me, now is the right time to come up with a better name
> EA> for this option. Maybe `gnus-registry-auto-create-entries', defaulted to
> EA> nil?)
>
> Yes, I'd be OK with that. Users may have customized
> `gnus-registry-extra-entries-precious' but I think it's unlikely.
Actually, thinking more about it, your point here is important -- it's
probably best to explicitly check the value of
`gnus-registry-extra-entries-precious'. Also, the good thing about
`gnus-registry-register-message-ids' is that it fully populates the
entries with sender, subject, etc. Relying on other manual functions to
create entries may fail to do that, and that information is important to
have.
I'm leaning towards having `gnus-registry-register-message-ids' do its
thing no matter what, and then deleting the entries when leaving the
*Summary* buffer. If the user adds precious data to any of the entries
while in the summary, they won't be deleted.
How does that sound?
On Tue, 16 Jun 2020 11:29:38 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote: EA> Actually, thinking more about it, your point here is important -- it's EA> probably best to explicitly check the value of EA> `gnus-registry-extra-entries-precious'. Also, the good thing about EA> `gnus-registry-register-message-ids' is that it fully populates the EA> entries with sender, subject, etc. Relying on other manual functions to EA> create entries may fail to do that, and that information is important to EA> have. EA> I'm leaning towards having `gnus-registry-register-message-ids' do its EA> thing no matter what, and then deleting the entries when leaving the EA> *Summary* buffer. If the user adds precious data to any of the entries EA> while in the summary, they won't be deleted. OK. For large groups, this gets slow in my experience. Could we register the articles when adding the marks or when leaving the summary? Ted
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Tue, 16 Jun 2020 11:29:38 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
> EA> Actually, thinking more about it, your point here is important -- it's
> EA> probably best to explicitly check the value of
> EA> `gnus-registry-extra-entries-precious'. Also, the good thing about
> EA> `gnus-registry-register-message-ids' is that it fully populates the
> EA> entries with sender, subject, etc. Relying on other manual functions to
> EA> create entries may fail to do that, and that information is important to
> EA> have.
>
> EA> I'm leaning towards having `gnus-registry-register-message-ids' do its
> EA> thing no matter what, and then deleting the entries when leaving the
> EA> *Summary* buffer. If the user adds precious data to any of the entries
> EA> while in the summary, they won't be deleted.
>
> OK. For large groups, this gets slow in my experience. Could we register
> the articles when adding the marks or when leaving the summary?
Oh, and that would make it even slower because the entries will be
constantly recreated if we happen to enter a group multiple times and
look at old messages.
We could create the full entries when setting marks, but that wouldn't
help other packages that might be using the registry to save
information. But perhaps we could create a helper function, or an
optional CREATE-FULL argument to `gnus-registry-set-id-key'.
Will think some more.