Re: Fixed bug with custom marks in registry

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Right now the thing that makes the most sense to me is:
>>
>> 1. Make a new group parameter that matches the "display" parameter that
>>    you can set for individual groups. Ie, we'd have a
>>    `gnus-parameter-display-alist' variable.
>> 2. Allow that parameter to take more than just a number to display: it
>>    should be a list, and allow pre-set symbols (like 'registry-marked,
>>    'registry-precious), and maybe functions? I haven't thought it all
>>    the way through.
>> 3. Consult that parameter when constructing Summary buffers.
>>
>> How's that sound?
>
> I guess it makes sense.  I don't use Gnus parameters much.

They're pretty handy!

> The approach that came to my mind would be to just factor out common
> parts and provide them as predefined functions.  For example, we could
> provide
>
> #+begin_src emacs-lisp
> (defun gnus-alter-articles-to-read-create-function (f)
>   (lambda (group-name article-list)
>     (cl-union
>      (delq nil
>            (mapcar (lambda (id) (cdr (gnus-request-head id group-name)))
>                    (cl-loop for key being the hash-keys of (oref gnus-registry-db data)
>                             using (hash-values v)
>                             when (funcall f v)
>                             collect key))))))
> #+end_src
>
>
> and the user could do
>
> #+begin_src emacs-lisp
> (add-function
>  :around gnus-alter-articles-to-read-function
>  (defun my-gnus-to-read-add-marked (orig-f group-name article-list)
>    (cl-union (funcall (gnus-alter-articles-to-read-create-function
>                        (lambda (v) (cdr (assoc 'mark v))))
>                       group-name article-list)
>              (funcall orig-f group-name article-list))))
> #+end_src
>
> The advantage would be that this doesn't require knowledge about
> database internals, and would provide a maximum of configurability.

But this seems to require just enough knowledge of the database
internals (and Gnus internals) to be offputting to regular users, while
not saving expert users all that much effort.

> Would that approach be compatible with your proposal?

I guess what I want is an approach that works earlier in the process and
adds/filters efficiently, altering the list of articles to read *before*
requesting heads (or at least not requesting redundant heads then doing
`cl-union' afterwards), and also providing a list of no-brainer default
options.

Then `gnus-alter-articles-to-read-function' could be applied on top of
this, but it would be understood to be for expert users to do custom
tweaking with -- and probably not very performantly.

E