Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: How about gnus-registry-precious-only-p?
Date: Fri, 12 Jun 2020 09:04:36 -0700	[thread overview]
Message-ID: <87ftb0l17v.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <a71cb4g4.fsf@lifelogs.com>

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.



  reply	other threads:[~2020-06-12 16:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 19:47 Eric Abrahamsen
2020-06-09 16:15 ` Ted Zlatanov
2020-06-12 16:04   ` Eric Abrahamsen [this message]
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=87ftb0l17v.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).