Re: [PATCH] Two issues with the gnus-registry

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Hi there,
>
> I'm using the gnus-registry in Gnorb to keep track of correspondences
> between Gnus messages and Org headings, using a key on the registry
> entries called 'gnorb-ids. This is meant to be a "precious" key, ie
> entries with this key are not pruned. So far so good:
>
> (oref gnus-registry-db :precious) => (gnorb-ids mark)
>
> But the entries still do get pruned! I've just had tracked entries start
> disappearing on me, and realized that they're getting pruned from the
> registry when I save it. There appear to be two problems here:

[...]

> And I really don't know why the precious entries are getting pruned.
> In a day or so, when I have more time, I'll test with a dummy registry,
> with max-entries set to 10 and 'creation-time added to the precious
> entries -- should make debugging easier.

Okay, I got curious (frustrated) and tried this, and I just don't get
it. `registry-prune' doesn't seem to work as advertised: first it
deletes according to `registry-prune-soft-candidates', which preserves
precious entries, and then it deletes according to
`registry-prune-hard-candidates', which doesn't.p

The second pass unconditionally caps the registry length at 90% of
`gnus-registry-max-entries', without consulting the entries' precious
status at all.

The `prune-needed' local variable also appears unused.

My understanding of the process is that the two functions should create
their two separate sets (entries over 90% of
`gnus-registry-max-entries', and non-precious entries), and then the
intersection of those two sets should be deleted.

Done this way, sorting would be cheaper as well -- you'd only need to
sort candidates by age for the hard-prune set.

I'm still pretty confused, but I can prepare a patch for this. Perhaps
I'm misreading the code, but I can't see how!

Eric