Re: Moving kbd to subr.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> definition of 'read-kbd-macro' into it, and adjusting it to no longer
>> use CL-Lib functions.
>
> No NEWS entry?

I consider this as an internal change that should have no user impact.
So I'm not sure this needs a NEWS-entry; if you think it does, please
clarify what you think we should put in it.

>> * lisp/subr.el (internal--kbd): Factor out from 'kbd'.  Change
>> this new function to be suitable for calling from both 'kbd' and
>> 'edmacro-parse-keys'.
>> * lisp/edmacro.el (edmacro-parse-keys): Replace definition with a
>> call to 'internal-kbd'.
>
> No sure I understand: the rationale for introducing internal--kbd
> instead of using kbd directly is because we need an extra optional
> argument?  if so, why not add that argument to kbd itself?

We could, but I feel like that's an implementation detail: an artifact
of the fact that kbd and edmacro-parse-keys share code.  I don't think
the parameter will be useful to users of kbd, and therefore risks
confusing instead.  So adding a new internal function seemed like a
small price to pay.

I have added this comment to the beginning of the function to make the
reasoning clear:

  ;; NB. This function exists mainly to avoid adding a "need-vector"
  ;;     argument to the user-facing function `kbd'.