I currently use a modified versions of the keybinding macros that use
`keymap-set` and other functions found in `keymap.el`. This resulted in
an error thrown when trying to use the new `kbd` ensure keyword. "C-="
can be set with `keymap-set`, but it will result an error in
`setup--ensure` with `(kbd "C-=")`.
So, I figured it may be useful to allow for custom ENSURE-SPECs. The
implementation below uses `cl-defgeneric` to allow for custom methods;
however, if you do not want to rely on the `cl-lib` library, I have a
patch that uses an alist variable instead. This seemed a bit cleaner to
me.
For example, this is the spec that I use for by custom `:bind` macros:
(cl-defmethod setup-ensure-spec ((spec (eql key-valid)) arg)
(if (key-valid-p arg)
arg
(setup-ensure-spec 'kbd arg)))
Do you think this is something you would be interested in?
I get the impression that cl-defmacro is too great of an overhead here
-- especially when we consider loading the necessary files during
initialisation. `Setup' is relatively fast, and if there is a more
efficient/lightweight way then I think it would be preferable.
Dispatching ensure-specs could also be done using an alist mapping
symbols to functions. That being said, I wonder if this is really so
much potential for extending `setup--ensure' or if simply extending it
We could also just require it if these ensure specs are used, and as I
don't intend to raise the minimum version of setup.el that soon, this
couldn't be a hard dependency.
My thoughts if you allow for user customization:
- Remove any future responsibility of adding to `setup--ensure'
- Additonally you could continue to add examples to the Wiki
for popular/commonly used specs.
Yeah, but that is my point. What other specs do you think there are
that should be added. My intuition is that there is an upper bound to
how many there can be, but I might be wrong.
"Philip Kaludercic" <philipk@posteo.net> writes:
> I get the impression that cl-defmacro is too great of an overhead here
> -- especially when we consider loading the necessary files during
> initialisation. `Setup' is relatively fast, and if there is a more
> efficient/lightweight way then I think it would be preferable.
> Dispatching ensure-specs could also be done using an alist mapping
> symbols to functions.
That makes sense. There should be a new patch attached below. I'm not
extremely familiar with the email patch workflow, so I hope that is okay
As I mentioned in my other message, don't worry about it. Just remember
to CC the mailing list by using some kind of a wide-reply so that the
conversation gets recorded on the mailing list.
> That being said, I wonder if this is really so
> much potential for extending `setup--ensure' or if simply extending it
> from time to time is the good enough of a solution?
If `setup--ensure' were to be extended, would you need to require the
`keymap.el' library in this case?
We could also just require it if these ensure specs are used, and as I
don't intend to raise the minimum version of setup.el that soon, this
couldn't be a hard dependency.
My thoughts if you allow for user customization:
- Remove any future responsibility of adding to `setup--ensure'
- Additonally you could continue to add examples to the Wiki
for popular/commonly used specs.
Yeah, but that is my point. What other specs do you think there are
that should be added. My intuition is that there is an upper bound to
how many there can be, but I might be wrong.
> Especially when we keep in mind that for infrequent objects it is often
> just easier to preform the check yourself in the local macro instead of
> using an ensure-spec.
To your point, I guess it does not matter whether the logic sits in
`setup.el' or the macro itself. I just saw the ability added recently
and thought it would be useful to extend it.
Also, re: the patch. I wasn't sure if `setup-ensure-alist' should be a
`defcustom' or `defvar'.
I would use a backquote-here, then unquote the functions and sharp-quote
them again so that the byte-compiler can detect if they are renamed or
otherwise missing.
^
"Alist" should be brief enough.
^
mapping?
It would also be nice to go into some more detail what this a "spec
symbol" is even supposed to be, for users who have never heard of these
things before. Also, how should the function behave (how many arguments
of what kind, what does it return, side-effects or anything like that).
+ ((eq (car-safe arg) 'quote)+ `#',(cadr arg))+ ((symbolp arg)+ `#',arg)+ (arg)))+(defun setup--ensure (ensure-spec args &optional check-len)
"Ensure that ARGS matches the form of ENSURE-SPEC.
-The symbol `kbd' means to apply the function `kbd' to the-argument. The symbol `func' means to sharp-quote the argument.
Otherwise this looks good, when we address these issues I can push the
patch. Do you want to also add a change entry under the "News" section
in the package header?
BTW, have you signed the FSF CA? Since this is an ELPA package, I am
required to make sure that all significant contributors have done so.