bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33005: 27.0.50; Data loss with Gnus registry


From: Eric Abrahamsen
Subject: bug#33005: 27.0.50; Data loss with Gnus registry
Date: Wed, 10 Oct 2018 09:08:33 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> There were some bugs with registry pruning and precious entries, but
>> we fixed those quite a while ago. If you're running Emacs master, you
>> should have the Gnus that incorporates those fixes.
>
> Yes, I think so, too.  I have a normal recent Emacs master build.  I
> typically rebuild daily.
>
>> On the other hand, what you say above about the docstring makes me
>> wonder, as in Gnus master it doesn't say it would default to
>> (marks). You're not loading an external Gnus installation, are you?
>
> No, I'm not.  In emacs master branch, "doc/misc/gnus.texi" says
>
>   "default this is just @code{(marks)} so the custom registry marks are"
>
> in line 26197.  Not for you?

Sorry, I was looking at the option docstring, not the manual. I'll fix
that typo.

But that was my only easy solution, unfortunately. You could examine the
results of:

(registry-collect-prune-candidates gnus-registry-db
(registry-size gnus-registry-db) nil)

To verify that it is returning candidates that should not be returned.
Unfortunately that function uses `cl-loop', which makes edebugging not
very helpful.

Shameless plug: I'm about to propose a new package called "gnus-mock",
which sets up a temporary/trashable/reproducible Gnus installation that
you can use for testing feature and hunting bugs, without endangering
your own Gnus data. That would be useful in this case. I might have it
done today.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]