Re: New key binding syntax

[John Yates <john@yates-sheets.org>]

On Fri, Nov 5, 2021 at 9:45 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> All characters usually count when dealing with strings.

That is true when the semantics are those of a string, e.g. printing.

It is rarely true when the string is a rendering in a domain-specific
language or notation intended to be parsed.  "C-x 2" is parsed as
as a sequence of items (keys) with whitespace serving to separate
the items.  Saying that " C-x  2 " cannot be parsed or, what would
be even more surprising, that it does parse but means something
different violates the principle of least astonishment.

Arguing that one clearly is dealing with a  _string_ is weakened
by the fact that today, in many settings, when Emacs outputs a
key sequence, it fails to enclose it in quotes.

> Which may say "C-c a runs the command (lambda nil", which doesn't tell
> you where it's defined.

Suggesting a possible enhancement to Emacs' representation
of lambdas.

It also represents an incentive for users not to use lambda in
key bindings.  Perhaps the documentation should have a
cautionary list of downsides to using lambda in keybindings.

> > Finally, I will point out that you are retracting current keydef
> > functionality.
>
> I'm not sure what you mean here.  The entire point here is to move away
> from five different key definition syntaxes to one syntax.  So of course
> I'm "retracting" functionality.

I was referring to handling of whitespace by Dave Gillespie's
nearly thirty year old edmacro.el, the basis for John Wiegley's
use-package key binding functionality.  From edmacro-mode's
doc string:

| Text is divided into \"words\" separated by whitespace.  Except for
| the words described below, the characters of each word go directly
| as characters of the macro.  The whitespace that separates words
| is ignored.  Whitespace in the macro must be written explicitly,
| as in \"foo SPC bar RET\".

I can vouch for the fact that edmacro, as invoked by use-package,
accepts arbitrary leading, intervening and trailing whitespace.