Re: Fixed bug with custom marks in registry

[Michael Heerdegen <michael_heerdegen@web.de>]

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.

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.

Would that approach be compatible with your proposal?


Michael.