On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@posteo.net>
wrote:


> E.g. `display-buffer-alist' makes use of it to associate display-buffer
> rules with buffers.  Now you can add
>
>       ((major-mode . help-mode) display-buffer-in-side-window)
>
> instead of trying to match being a regular expression to catch all
> *Help* buffer names of a function along the lines of
>
>       (lambda (buf _alist)
>         (with-current-buffer buf
>           (derived-mode-p 'help-mode)))
>

If you really want to save up on this typing, it's better to define
a reusable helper function, or even a higher order function.

  (defun buffer-mode-matcher (mode)
    (lambda (b _alist)
      (with-current-buffer b (derived-mode-p 'help-mode))))

You can add buffer-mode-matcher to the library if it becomes
useful enough.  Then you add:

  `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)

to display-buffer-alist.

But if you really want a new language your language, then I suggest
a simple adapter buffer-matcher utility that merges the two.  That way one
doesn't couple existing utilities to the new mini-language and
simultaneously
the new mini-language become useful in a much wider setting for those who
appreciate such things.

  (defun buffer-matcher (condition)
     "Return unary predicate of a buffer matching the CONDITION
mini-language."
    (lambda (buf &rest _whatever) ; make it even more lax
       (buffer-match-p condition)))

Later on, you might even pass an (... &optional compiled) so that the
return value
is syntax checked and optimized in some way at compile time.

IOW, (E)Lisp already gives you the tools for these composition without
needing to invent new languages with the drawbacks I listed.