Re: Gnus: Thread notes?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

[...]

> I think you could factor this defun so that it would be possible to set
> `gnus-alter-articles-to-read-function' to one factor, then AFAICT,
> automatic listing of tracked messages should be possible.

Interesting! I'd never looked at that option before. I'd still like to
keep the manual command, for those who don't want this to happen
automatically, but yes, it wouldn't be hard to refactor.

It would also require some sort of internal caching first -- right now
it's too slow to have it running each time you enter a group.

> If you care about Gnus, two things that came to my mind when fiddling
> with this stuff:
>
> (1) I think `gnus-alter-articles-to-read-function' should better default
> to a function (lambda (_group-name article-list) article-list), not to
> nil, so that one could use `add-function' on it.

Or the code could coerce the value to a list, and map all the functions.
Maybe that would be more intuitive than `add-function'?

> (2) (info "(gnus) Store arbitrary data") is missing a function that can
> be used to delete the entry of a key for an ID.  One can only associate
> a key to nil, but that doesn't remove the association from the database;
> it still contains the association key -> nil for ID.

The idea with the registry is that it's sort of a catch-all slush
bucket. I think it's expected that it will fill up rather quickly, and
then get pruned as necessary. Ie, I don't think it matters that there
are useless associations in there, only that "precious" associations
aren't pruned.

I've been thinking for a while about providing the option to have Gnorb
use a separate registry. The way the registry works now, there's so much
churn it's not really feasible to keep it in version control.

Eric