Add simple affix dispatcher

[minad]

Add simple affix dispatcher

[oantolin]

I guess orderless-affix-dispatcher is the most descriptive.

[minad]

Editing the title to reflect the status of the discussion ;)

[minad]

One could also make the dispatcher slightly more general with a configuration which allows you to configure prefix and suffix separately:

(defvar orderless-default-dispatch-affixes
  `((?%  ?%  ,#'char-fold-to-regexp)
    (?!  nil ,#'orderless-without-literal)
    (?,  ?,  ,#'orderless-initialism)
    (nil ?=  ,#'orderless-literal)
    (nil ?~  ,#'orderless-flex)))

But that's probably overdoing it and users who want such special behavior can always write their own dispatcher. The goal here is to provide a simple dispatcher which would work for 90% of the users, in particular beginners starting with Orderless/Vertico etc.

[oantolin]

Sure, I'll add it. I see no harm in adding such a dispatcher, it won't mess up the configuration of people who already have dispatchers set up (unless they add them to orderless-style-dispatchers rather than setting the variable, but that seems very unlikely). I just need to document it and give orderless-default-dispatch-alist a nice custom type.

[minad]

Okay, great. I also think that the addition is not harmful, since it does not add much code. It should also resolve #83. The only thing which remains is the bikeshedding discussion regarding the name of the dispatcher.

• orderless-affix-dispatcher
• orderless-char-dispatcher
• orderless-simple-dispatcher
• orderless-default-dispatcher
• ...

What do you think?

[oantolin]

Done. Please take a look at the docstring and changes to the manual, if you can, to see if things are clear.

[minad]

@oantolin Thanks, looks good, except for two small details. I commented directly in the commit. Please take a look.

[oantolin]

Thanks for pointing those out!

[minad]

Btw, regarding length= what do you think about using Compat? It won't be useful for Orderless, but it may make sense to take advantage of it in Embark. I use it in all my packages (including the smaller ones), but that's of course my personal bias.

It is used by the current development version of Magit (and other packages by Jonas). It will likely be used by Org too in the future, see https://lists.gnu.org/archive/html/emacs-orgmode/2023-01/msg00919.html. At this point the flood gates are open and Compat will be like an established standard library which is around anyway. This also makes sense given that Compat just implements parts of the standard library.

EDIT: Forgot to mention, I already added Compat to Marginalia.

[oantolin]

I've been thinking about using it for Embark and maybe removing the embark-define-keymap macro in favor of defvar-keymap.

[minad]

I've been thinking about using it for Embark and maybe removing the embark-define-keymap macro in favor of defvar-keymap.

Yes, it is good idea to get rid of this macro (better sooner than later). In retrospect it was a mistake to make this public. I've seen many downstream packages which integrated Embark support to start depending on Embark solely because of embark-define-keymap. In all these cases I had to intercept when the packages got proposed for MELPA. Iirc it happened basically for every single package at their first Embark integration attempt. :-P

Multiple packages integrate with Embark now in the correct way, via only a few lines of with-eval-after-load and without depending on Embark. See for example Prot's TMR, where I added support:

https://github.com/protesilaos/tmr/blob/9db3306908dbbeed948438c8a04445e98e684f68/tmr.el#L480-L505