Gnus development mailing list
 help / color / mirror / Atom feed
* How about gnus-registry-precious-only-p?
@ 2020-05-20 19:47 Eric Abrahamsen
  2020-06-09 16:15 ` Ted Zlatanov
  2020-06-12 14:46 ` Bob Newell
  0 siblings, 2 replies; 8+ messages in thread
From: Eric Abrahamsen @ 2020-05-20 19:47 UTC (permalink / raw)
  To: ding

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-05-20 19:47 How about gnus-registry-precious-only-p? Eric Abrahamsen
@ 2020-06-09 16:15 ` Ted Zlatanov
  2020-06-12 16:04   ` Eric Abrahamsen
  2020-06-12 14:46 ` Bob Newell
  1 sibling, 1 reply; 8+ messages in thread
From: Ted Zlatanov @ 2020-06-09 16:15 UTC (permalink / raw)
  To: ding

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>



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-05-20 19:47 How about gnus-registry-precious-only-p? Eric Abrahamsen
  2020-06-09 16:15 ` Ted Zlatanov
@ 2020-06-12 14:46 ` Bob Newell
  1 sibling, 0 replies; 8+ messages in thread
From: Bob Newell @ 2020-06-12 14:46 UTC (permalink / raw)
  To: ding

> 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-06-09 16:15 ` Ted Zlatanov
@ 2020-06-12 16:04   ` Eric Abrahamsen
  2020-06-16 17:08     ` Ted Zlatanov
  0 siblings, 1 reply; 8+ messages in thread
From: Eric Abrahamsen @ 2020-06-12 16:04 UTC (permalink / raw)
  To: ding

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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-06-12 16:04   ` Eric Abrahamsen
@ 2020-06-16 17:08     ` Ted Zlatanov
  2020-06-16 18:29       ` Eric Abrahamsen
  0 siblings, 1 reply; 8+ messages in thread
From: Ted Zlatanov @ 2020-06-16 17:08 UTC (permalink / raw)
  To: ding

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>



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-06-16 17:08     ` Ted Zlatanov
@ 2020-06-16 18:29       ` Eric Abrahamsen
  2020-06-16 19:08         ` Ted Zlatanov
  0 siblings, 1 reply; 8+ messages in thread
From: Eric Abrahamsen @ 2020-06-16 18:29 UTC (permalink / raw)
  To: ding

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?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-06-16 18:29       ` Eric Abrahamsen
@ 2020-06-16 19:08         ` Ted Zlatanov
  2020-06-16 21:46           ` Eric Abrahamsen
  0 siblings, 1 reply; 8+ messages in thread
From: Ted Zlatanov @ 2020-06-16 19:08 UTC (permalink / raw)
  To: ding

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: How about gnus-registry-precious-only-p?
  2020-06-16 19:08         ` Ted Zlatanov
@ 2020-06-16 21:46           ` Eric Abrahamsen
  0 siblings, 0 replies; 8+ messages in thread
From: Eric Abrahamsen @ 2020-06-16 21:46 UTC (permalink / raw)
  To: ding

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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-06-16 21:47 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-20 19:47 How about gnus-registry-precious-only-p? Eric Abrahamsen
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

Gnus development mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/ding

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 ding ding/ http://inbox.vuxu.org/ding \
		ding@inbox.vuxu.org
	public-inbox-index ding

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.emacs.gnus.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git