Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

larsi@gnus.org (Lars Ingebrigtsen) writes:

> +(defun lisp-indent--defvar-keymap (state)
> +  "Return the indent position in the options part of a `defvar-keymap' form."

After pushing this, it strikes me that perhaps we should just indent all
lists that start with a keyword this way?

That is

(:foo 1
 :zot 2)

instead of

(:foo 1
      :zot 2)

as it's currently done.  Any objections?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Adam Porter]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> After pushing this, it strikes me that perhaps we should just indent all
> lists that start with a keyword this way?
>
> That is
>
> (:foo 1
>  :zot 2)
>
> instead of
>
> (:foo 1
>       :zot 2)
>
> as it's currently done.  Any objections?

That includes quoted lists, like:

  '(:foo 1
    :zot 2)

right?  If so, yes, please.

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

Adam Porter <adam@alphapapa.net> writes:

> That includes quoted lists, like:
>
>   '(:foo 1
>     :zot 2)
>
> right?  If so, yes, please.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Madhu]

* Lars Ingebrigtsen <874k9xnlmx.fsf@gnus.org> :
Wrote on Mon, 04 Oct 2021 12:13:10 +0200:

> Adam Porter <adam@alphapapa.net> writes:
>
>> That includes quoted lists, like:
>>
>>   '(:foo 1
>>     :zot 2)
>>
>> right?  If so, yes, please.

BTW To get the similar behaviour with cl-indent I had the following
kludge for "(:def*" forms.  Maybe there is a better way to do this?

diff --git a/lisp/emacs-lisp/cl-indent.el b/lisp/emacs-lisp/cl-indent.el
index 26507578c32..98ccc68ddc4 100644
--- a/lisp/emacs-lisp/cl-indent.el
+++ b/lisp/emacs-lisp/cl-indent.el
@@ -351,6 +351,7 @@ common-lisp-indent-function-1
                     method (lisp-indent-find-method tem))
               ;; The pleblisp package feature
               (when (and (null tem)
+			 (not (string-match "^:" function)) ;XXX 090210
                          (string-match ":[^:]+" function))
                 (setq function (substring function (1+ (match-beginning 0)))
                       tem (intern-soft function)
@@ -390,6 +391,8 @@ common-lisp-indent-function-1
                    (setq method lisp-indent-defun-method)))
 
             (cond ((and (or (eq (char-after (1- containing-sexp)) ?\')
+			    (and (eq (char-after (1+ containing-sexp)) ?\:) ;XXX 090509
+				 (= depth 0))
 			    (and (not lisp-backquote-indentation)
 				 (eq (char-after (1- containing-sexp)) ?\`)))
                         (not (eq (char-after (- containing-sexp 2)) ?\#)))
.

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Jonas Bernoulli]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Adam Porter <adam@alphapapa.net> writes:
>
>> That includes quoted lists, like:
>>
>>   '(:foo 1
>>     :zot 2)
>>
>> right?  If so, yes, please.
>
> Yup.

Please consider also doing this for vectors,
which after all are seldom function calls. ;)

[:foo 1
 :zot 2]

     Jonas

Change indentation of keyword lists/arrays

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Please consider also doing this for vectors,
> which after all are seldom function calls. ;)
>
> [:foo 1
>  :zot 2]

Sure, makes sense.

So -- the suggestion is to change the indentation of

(:foo 2
      :bar 2)  

to

(:foo 2
 :bar 2)

and that goes for

'(:foo 2
  :bar 2)

too.  Function names can start with a : though, so in the () case,
perhaps this is a heuristic we want to avoid?  I can't seeing anybody
write 

(defun :foo (a)
  a)

though.  But heuristics suck, so perhaps we don't want to do this?

The vector case is simpler...  but shouldn't all vectors be indented
like that, no matter whether there's a keyword in the mix or not.  I.e.,
I don't think anybody really wants to see

[a b
   c d]

I'm sure nobody has any opinion on this matter.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Change indentation of keyword lists/arrays

[Juri Linkov]

> and that goes for
>
> '(:foo 2
>   :bar 2)
>
> too.  Function names can start with a : though, so in the () case,
> perhaps this is a heuristic we want to avoid?  I can't seeing anybody
> write
>
> (defun :foo (a)
>   a)
>
> though.

Please change the indentation of quoted lists.  It takes
too much time to manually delete excessive indentation
every time with C-d C-d C-d C-d C-d C-d C-d ... to turn such code:

  (memq this-command
        '(universal-argument universal-argument-more
                             digit-argument negative-argument))

to more readable:

  (memq this-command
        '(universal-argument universal-argument-more
          digit-argument negative-argument))

Re: Change indentation of keyword lists/arrays

[Tassilo Horn]

Juri Linkov <juri@linkov.net> writes:

> Please change the indentation of quoted lists.  It takes
> too much time to manually delete excessive indentation
> every time with C-d C-d C-d C-d C-d C-d C-d ... to turn such code:
>
>   (memq this-command
>         '(universal-argument universal-argument-more
>                              digit-argument negative-argument))
>
> to more readable:
>
>   (memq this-command
>         '(universal-argument universal-argument-more
>           digit-argument negative-argument))

Don't we use

   (memq this-command
         '( universal-argument universal-argument-more
            digit-argument negative-argument))

with the space after the paren to indicate that this is surely just a
"data list" and no (possibly quoted) funcall (being eval-ed later).

Bye,
Tassilo

Re: Change indentation of keyword lists/arrays

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Please change the indentation of quoted lists.  It takes
> too much time to manually delete excessive indentation
> every time with C-d C-d C-d C-d C-d C-d C-d ... to turn such code:
>
>   (memq this-command
>         '(universal-argument universal-argument-more
>                              digit-argument negative-argument))
>
> to more readable:
>
>   (memq this-command
>         '(universal-argument universal-argument-more
>           digit-argument negative-argument))

This style was added some time back, and is currently the recommended
way to get this indentation:

(memq this-command
      '( universal-argument universal-argument-more
         digit-argument negative-argument))

Heh.  But I see that doing the same for a vector signals an error:

[ :foo :zot
      :bar]

forward-sexp: Scan error: "Containing expression ends prematurely", 1, 1

(I'll open a bug report.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Change indentation of keyword lists/arrays

[Drew Adams]

> This style was added some time back, and is currently the recommended
> way to get this indentation:
> 
> (memq this-command
>       '( universal-argument universal-argument-more
>          digit-argument negative-argument))

Some time back?  Recommended where, by whom?  And why?

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Stefan Monnier]

> +@item :copy
> +If non-@code{nil}, copy this keymap and use it as the basis
> +(@pxref{Creating Keymaps}).

Could we remove this option?  I think we shouldn't encourage use of
`copy-keymap`, and I can't remember the last time I needed to copy
a keymap: inheritance works as well.


        Stefan

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +@item :copy
>> +If non-@code{nil}, copy this keymap and use it as the basis
>> +(@pxref{Creating Keymaps}).
>
> Could we remove this option?  I think we shouldn't encourage use of
> `copy-keymap`, and I can't remember the last time I needed to copy
> a keymap: inheritance works as well.

I wanted to have a feature set that would enable rewriting all
-mode-maps without any change in the resulting maps, and `copy-keymap'
is used in a few of them.  So I added it, even though it's obscure to me
why it's being used...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Stefan Monnier]

> I wanted to have a feature set that would enable rewriting all
> -mode-maps without any change in the resulting maps, and `copy-keymap'
> is used in a few of them.  So I added it, even though it's obscure to me
> why it's being used...

I think most/all uses of `copy-keymap` are ill-advised.
So the conversion is a good opportunity to fix those.


        Stefan

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think most/all uses of `copy-keymap` are ill-advised.
> So the conversion is a good opportunity to fix those.

Most of the usages are indeed errors, but I seem to remember grepping
around and finding instances where looked like it was useful.  Uhm...  I
think it was someone both copying a parent and then making something
else a parent of the keymap?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Most of the usages are indeed errors, but I seem to remember grepping
> around and finding instances where looked like it was useful.  Uhm...  I
> think it was someone both copying a parent and then making something
> else a parent of the keymap?

On the other hand, for those very rare, complicated cases, the user can
just pass in the oddball keymap with :keymap (copy-keymap foo-map) or
whatever, so that we don't have to have :copy in the signature.

OK, I'll remove the :copy keyword.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Stefan Monnier]

> around and finding instances where looked like it was useful.  Uhm...  I
> think it was someone both copying a parent and then making something
> else a parent of the keymap?

Sounds like the kind of gymnastics that was done back when we only had
single inheritance.


        Stefan

Re: master 192f935 1/3: Add 'define-keymap' and 'defvar-keymap'

[Lars Ingebrigtsen]

By the way, when looking at how this is byte-compiled, I was surprised
to find that there's a lot of byte code in what's basically just a call
to a function with two parameters (that are both lists), so I had a look
at what's happening.

If a defvar is a single list, it's byte-compiled as a single list.  So
the first form results in the second in the .elc file:

(defvar foo-foo
  (list :foo "bar" "f" #'forward-line  "b" #'previous-line))

(defvar foo-foo (list :foo "bar" "f" 'forward-line "b" 'previous-line))

But if we involve more things, like this:

(defvar foo-foo
  (list (list :foo "bar") "f" #'forward-line  "b" #'previous-line))

(defvar foo-foo (byte-code "\300\301D\302\303\304\305\257^E\207" [:foo "bar" "f" forward-line "b" previous-line] 5))

The latter is longer both in the .elc file and in-memory size (if
memory-report is to be believed), and presumably also takes longer to
execute?  We've got a whole lot of defvars in Emacs that are basically
lists, so I wonder whether this is something that should be tweaked in
the byte compiler?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

larsi@gnus.org (Lars Ingebrigtsen) writes:

> branch: master
> commit 859190f03e87601324d394178d90e6dea5cd4002
> Author: Lars Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Ingebrigtsen <larsi@gnus.org>
>
>     Convert some keymaps to defvar-keymap

Any chance we could make these new macros use `kbd' by default?

I find e.g. "C-c C-m C-a" or "C-x SPC" more readable than
"\C-c\C-m\C-a", "\C-x " "[?\S-\ ]", etc., as it looks more like what
you would see in our documentation.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Any chance we could make these new macros use `kbd' by default?
>
> I find e.g. "C-c C-m C-a" or "C-x SPC" more readable than
> "\C-c\C-m\C-a", "\C-x " "[?\S-\ ]", etc., as it looks more like what
> you would see in our documentation.

You mean all strings would be run through `kbd' by `define-keymap'?
Sounds confusing to me.  But when converting a keymap, the person doing
the conversion could change the strings to kbd calls.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> You mean all strings would be run through `kbd' by `define-keymap'?

Yes.

> Sounds confusing to me.

Why?  Isn't it just the same thing written in a way that is easier to
read?  IOW, how is "C-x SPC" more confusing than "\C-x "?

I feel like I am missing something.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Sounds confusing to me.
>
> Why?  Isn't it just the same thing written in a way that is easier to
> read?  IOW, how is "C-x SPC" more confusing than "\C-x "?

It's confusing because it'd be a different syntax for define-key and
define-keymap.

If we were redesigning all the Emacs keymap functions from scratch, I'd
go with the `kbd' syntax for keys, but unfortunately we aren't.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's confusing because it'd be a different syntax for define-key and
> define-keymap.
>
> If we were redesigning all the Emacs keymap functions from scratch, I'd
> go with the `kbd' syntax for keys, but unfortunately we aren't.

Aha.  Now I understand the argument.  But surely that's pretty minor,
given that we can just document this difference?  People might
appreciate the easier to read syntax many times more than they will
struggle with this minor additional complexity.

It seems somewhat unfortunate to me that we are effectively doubling
down on the mistakes of the past.  I'd rather take one step forward now,
in the hope that we can do something about "define-key" later.

I think it's clear that an important section of the Emacs user-base
values a more succinct and clear style higher than the idioms and
idiosyncrasies of the past.  This has affected Emacs in many positive
ways over the years, see for example how dash.el prompted the
development of seq.el, etc.

With regards to keybindings, I think many agree with you that the kbd
syntax is better.  But people are not sitting still.  On the contrary,
there is a lot of experimentation taking place in third-party packages
specifically to avoid having to use `define-key'.  See e.g.:

    https://github.com/jwiegley/use-package/blob/master/bind-key.el
    https://github.com/noctuid/general.el
    https://github.com/justbur/emacs-which-key#keymap-based-replacement
    https://evil.readthedocs.io/en/latest/keymaps.html#evil-define-key

Over time, and if we don't take action, this risks leading to a
proliferation in various conflicting and incompatible styles, that all
depend on this or that third-party package.  Meanwhile, Emacs yet again
looks archaic and too stuck in our old ways.

I suggest that we would do better, and perhaps partially pre-empt such a
development, by taking a pro-active stance with a new construct like
`define-keymap'.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Aha.  Now I understand the argument.  But surely that's pretty minor,
> given that we can just document this difference?  People might
> appreciate the easier to read syntax many times more than they will
> struggle with this minor additional complexity.

Well, we have a bunch of different key syntaxes, and two of them are
strings and therefore aren't marked as syntactically different.

> It seems somewhat unfortunate to me that we are effectively doubling
> down on the mistakes of the past.  I'd rather take one step forward now,
> in the hope that we can do something about "define-key" later.

I don't think that's a forlorn hope.  We'd have to introduce a new
function. 

> I suggest that we would do better, and perhaps partially pre-empt such a
> development, by taking a pro-active stance with a new construct like
> `define-keymap'.

In the current Emacs tree, we have >7K instances of define-key with a
string as a parameter, and 441 with (kbd ...).  If `kbd' had made
greater headway in the...  decades since it was added, then it would
have been a more obvious choice to go for the kbd syntax in
define-keymap, but it hasn't -- it's not obvious that "C-c C-c" is a
better syntax than "\C-c\C-c" from the usage stats.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> In the current Emacs tree, we have >7K instances of define-key with a
> string as a parameter, and 441 with (kbd ...).

And 258 on the [(control ?+)].

(And as Eli said, `kbd' isn't something that we currently can use
everywhere, because the implementation depends on (basically)
everything.  If the `kbd' syntax is to be used in keymaps everywhere,
somebody has to re-implement it to be self contained.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> In the current Emacs tree, we have >7K instances of define-key with a
>> string as a parameter, and 441 with (kbd ...).
>
> And 258 on the [(control ?+)].

Right, but how much of that is preloaded code, how much is unchanged
since the 1990's, how much is written by core developers who can't use
`kbd' due to bootstrap and just got out of the habit, etc.?

In my case, I would definitely prefer to use kbd everywhere, but it
feels out of place to convert an entire string of bindings to my
preferred style just because I'm adding a keybinding.  So I don't do
that.

IOW, I don't think that counting instances in core will necessarily lead
to a very representative sample of current Emacs Lisp in this case.

For comparison, here are the top packages on MELPA, excluding dash.el
and other library packages without keybindings:

https://github.com/magit/magit/blob/348d9b98614c824be3e2f05eef5ab91d67f6695e/lisp/magit.el#L283
https://github.com/emacs-helm/helm/blob/b2bd8a2a938030c70e7da84bd49cadcc095ec2b9/helm.el#L212
https://github.com/flycheck/flycheck/blob/784f184cdd9f9cb4e3dbb997c09d93e954142842/flycheck.el#L1096
https://github.com/bbatsov/projectile/blob/7f64570d3e6829d767d340c8584f3e4f3472ee81/projectile.el#L5377
https://github.com/company-mode/company-mode/blob/4c08ef468678bbf3b3c9e750f6e694eea1aa8423/company.el#L807
https://github.com/jrblevin/markdown-mode/blob/862ae8addd29bf6affca1a35fd0176cb0c1392da/markdown-mode.el#L5316

Six different principal authors, but all of them use kbd.  I stopped
checking after markdown-mode, but all I checked before that uses kbd.

> (And as Eli said, `kbd' isn't something that we currently can use
> everywhere, because the implementation depends on (basically)
> everything.  If the `kbd' syntax is to be used in keymaps everywhere,
> somebody has to re-implement it to be self contained.)

Yeah, that would need fixing if we want to use it in preloaded code.

From a quick glance, it looks like the meat of this is in
`edmacro-parse-keys'.  From there, you have a ton of calls to `cl-lib',
regexps and what have you.  But nothing in there looks like it should be
impossible to get in shape, even for early bootstrap, does it?

Personally though, I'd be quite happy even if we could just do what Juri
said and add a :kbd keyword to defvar-keymap (t by default), and use
:kbd nil in our preloaded code.  I'm pretty sure that at least the above
package authors (the "kbd" users) would also be happy.  It's too nice of
an addition to Emacs Lisp to not get it all the way over the finish
line when we have the chance.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>>> In the current Emacs tree, we have >7K instances of define-key with a
>>> string as a parameter, and 441 with (kbd ...).

Actually, when thinking about this a bit more, perhaps the potential for
confusion is radically lower than I first imagined.

That is,

(equal (kbd "\C-xf") (kbd "C-x f"))
=> t

So even if somebody uses "\C-xf" in `define-keymap' (and we're running
all the string values through `kbd'), then it won't actually break
anything.

If somebody's writing "C-x" to bind the three letter sequence `C - x',
they'll be surprised, but I don't think anybody has ever bound such a
sequence, so...

On the fourth hand, perhaps this "it just works anyway" thing would make
things even more confusing -- I mean, it'd "just work" no matter what
syntax you use, except in rare corner cases.

> Right, but how much of that is preloaded code, how much is unchanged
> since the 1990's, how much is written by core developers who can't use
> `kbd' due to bootstrap and just got out of the habit, etc.?

Might be a lot due to the bootstrap sitch -- if you can't use it
everywhere, then best avoid it to avoid surprises.

> From a quick glance, it looks like the meat of this is in
> `edmacro-parse-keys'.  From there, you have a ton of calls to `cl-lib',
> regexps and what have you.  But nothing in there looks like it should be
> impossible to get in shape, even for early bootstrap, does it?

No, skimming that, it's much simpler than I imagined.  Rewriting that
and plonking it into subr.el would be nice.  I mean, I think we should
do that anyway, so that we can use `kbd' everywhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (equal (kbd "\C-xf") (kbd "C-x f"))
> => t

"\C-c\M-\C-a"
=> "^C\201"
(kbd "\C-c\M-\C-a")
=> [3 129]
(kbd "C-c M-C-a")
=> [3 134217729]

The first two are clearly the same :-), but what's up with the last
one...  oh, that's the meta bit?  Well, that's OK, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Moving kbd to subr.el

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, skimming that, it's much simpler than I imagined.  Rewriting that
> and plonking it into subr.el would be nice.  I mean, I think we should
> do that anyway, so that we can use `kbd' everywhere.

I've attached a quick proof-of-concept of moving the kbd implementation
to subr.el.  With this, all the tests I have assembled so far pass and
this bootstraps.  It was mostly just a case of ripping out the calls to
cl-lib functions.

If this is something we want to do, I can finish this patch up.  To
begin with, I'd want to look it all over for correctness and add more
tests (ideas welcome).  I guess it would also make sense to just change
`read-kbd-macro' to call kbd, instead of the other way around.

[-- Attachment #2: 0001-Move-read-kbd-macro-implementation-to-key-in-subr.el.patch --]
[-- Type: text/x-diff, Size: 7876 bytes --]

From aa35959c77e7b2de8f53c5c200057040a8b1aa57 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 13 Oct 2021 01:40:14 +0200
Subject: [PATCH] Move read-kbd-macro implementation to key in subr.el

---
 lisp/subr.el            | 102 +++++++++++++++++++++++++++++++++++++++-
 test/lisp/subr-tests.el |  29 +++++++++++-
 2 files changed, 128 insertions(+), 3 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index 805c14eae3..5522d46401 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -937,7 +937,107 @@ kbd
   ;; the calling convention of `kbd'.
   (declare (pure t) (side-effect-free t))
   ;; A pure function is expected to preserve the match data.
-  (save-match-data (read-kbd-macro keys)))
+  (save-match-data
+    (let ((case-fold-search nil)
+          (len (length keys)) ; We won't alter keys in the loop below.
+          (pos 0)
+          (res []))
+      (while (and (< pos len)
+                  (string-match "[^ \t\n\f]+" keys pos))
+        (let* ((word-beg (match-beginning 0))
+               (word-end (match-end 0))
+               (word (substring keys word-beg len))
+               (times 1)
+               key)
+          ;; Try to catch events of the form "<as df>".
+          (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
+              (setq word (match-string 0 word)
+                    pos (+ word-beg (match-end 0)))
+            (setq word (substring keys word-beg word-end)
+                  pos word-end))
+          (when (string-match "\\([0-9]+\\)\\*." word)
+            (setq times (string-to-number (substring word 0 (match-end 1))))
+            (setq word (substring word (1+ (match-end 1)))))
+          (cond ((string-match "^<<.+>>$" word)
+                 (setq key (vconcat (if (eq (key-binding [?\M-x])
+                                            'execute-extended-command)
+                                        [?\M-x]
+                                      (or (car (where-is-internal
+                                                'execute-extended-command))
+                                          [?\M-x]))
+                                    (substring word 2 -2) "\r")))
+                ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
+                      (progn
+                        (setq word (concat (match-string 1 word)
+                                           (match-string 3 word)))
+                        (not (string-match
+                              "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
+                              word))))
+                 (setq key (list (intern word))))
+                ((or (equal word "REM") (string-match "^;;" word))
+                 (setq pos (string-match "$" keys pos)))
+                (t
+                 (let ((orig-word word) (prefix 0) (bits 0))
+                   (while (string-match "^[ACHMsS]-." word)
+                     (setq bits (+ bits (cdr (assq (aref word 0)
+                                                   '((?A . ?\A-\^@) (?C . ?\C-\^@)
+                                                     (?H . ?\H-\^@) (?M . ?\M-\^@)
+                                                     (?s . ?\s-\^@) (?S . ?\S-\^@))))))
+                     (setq prefix (+ prefix 2))
+                     (setq word (substring word 2)))
+                   (when (string-match "^\\^.$" word)
+                     (setq bits (+ bits ?\C-\^@))
+                     (setq prefix (1+ prefix))
+                     (setq word (substring word 1)))
+                   (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
+                                              ("LFD" . "\n") ("TAB" . "\t")
+                                              ("ESC" . "\e") ("SPC" . " ")
+                                              ("DEL" . "\177")))))
+                     (when found (setq word (cdr found))))
+                   (when (string-match "^\\\\[0-7]+$" word)
+                     (let ((n 0))
+                       (dolist (ch (cdr (string-to-list word)))
+                         (setq n (+ (* n 8) ch -48)))
+                       (setq word (vector n))))
+                   (cond ((= bits 0)
+                          (setq key word))
+                         ((and (= bits ?\M-\^@) (stringp word)
+                               (string-match "^-?[0-9]+$" word))
+                          (setq key (mapcar (lambda (x) (+ x bits))
+                                            (append word nil))))
+                         ((/= (length word) 1)
+                          (error "%s must prefix a single character, not %s"
+                                 (substring orig-word 0 prefix) word))
+                         ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
+                               ;; We used to accept . and ? here,
+                               ;; but . is simply wrong,
+                               ;; and C-? is not used (we use DEL instead).
+                               (string-match "[@-_a-z]" word))
+                          (setq key (list (+ bits (- ?\C-\^@)
+                                             (logand (aref word 0) 31)))))
+                         (t
+                          (setq key (list (+ bits (aref word 0)))))))))
+          (when key
+            (dolist (_ (number-sequence 1 times))
+              (setq res (vconcat res key))))))
+      (when (and (>= (length res) 4)
+                 (eq (aref res 0) ?\C-x)
+                 (eq (aref res 1) ?\()
+                 (eq (aref res (- (length res) 2)) ?\C-x)
+                 (eq (aref res (- (length res) 1)) ?\)))
+        (setq res (apply #'vector (reverse (cdr (cdr (reverse (cdr (cdr (append res nil))))))))))
+      (if (let ((ret t))
+            (dolist (ch (append res nil))
+              (unless (and (characterp ch)
+                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                             (and (>= ch2 0) (<= ch2 127))))
+                (setq ret nil)))
+            ret)
+          (concat (mapcar (lambda (ch)
+                            (if (= (logand ch ?\M-\^@) 0)
+                                ch (+ ch 128)))
+                          (append res nil)))
+        res))))
 
 (defun undefined ()
   "Beep to tell the user this binding is undefined."
diff --git a/test/lisp/subr-tests.el b/test/lisp/subr-tests.el
index 32c0bc3ed3..7a89456037 100644
--- a/test/lisp/subr-tests.el
+++ b/test/lisp/subr-tests.el
@@ -87,13 +87,38 @@ subr-test-kbd
   (should (equal (kbd "f") "f"))
   (should (equal (kbd "<f1>") [f1]))
   (should (equal (kbd "RET") "\C-m"))
-  (should (equal (kbd "C-x a") "\C-xa"))
+
+  ;; Modifiers.
+  (should (equal (kbd "C-x a") "\^Xa"))
+  (should (equal (kbd "M-x a") [134217848 97]))
+  (should (equal (kbd "H-x a") [16777336 97]))
+  (should (equal (kbd "s-x a") [8388728 97]))
+  (should (equal (kbd "S-x a") [33554552 97]))
+
+  ;; Special characters.
+  (should (equal (kbd "NUL") "\0"))
+  (should (equal (kbd "LFD") "\n"))
+  (should (equal (kbd "ESC") "\e"))
+  (should (equal (kbd "SPC") "\s"))
+  (should (equal (kbd "DEL") "\^?"))
+  (should (equal (kbd "TAB") "\t"))
+
+  ;; With numbers.
+  (should (equal (kbd "\\000") "\0"))
+  (should (equal (kbd "C-x \\150") "\C-xh"))
+
   ;; Check that kbd handles both new and old style key descriptions
   ;; (bug#45536).
   (should (equal (kbd "s-<return>") [s-return]))
   (should (equal (kbd "<s-return>") [s-return]))
   (should (equal (kbd "C-M-<return>") [C-M-return]))
-  (should (equal (kbd "<C-M-return>") [C-M-return])))
+  (should (equal (kbd "<C-M-return>") [C-M-return]))
+
+  ;; Error.
+  (should-error (kbd "C-xx"))
+
+  ;; These should be equivalent:
+  (should (equal (kbd "\C-xf") (kbd "C-x f"))))
 
 (ert-deftest subr-test-define-prefix-command ()
   (define-prefix-command 'foo-prefix-map)
-- 
2.30.2

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I've attached a quick proof-of-concept of moving the kbd implementation
> to subr.el.  With this, all the tests I have assembled so far pass and
> this bootstraps.  It was mostly just a case of ripping out the calls to
> cl-lib functions.

I haven't tried it, but it looks good to me.

> If this is something we want to do, I can finish this patch up.  To
> begin with, I'd want to look it all over for correctness and add more
> tests (ideas welcome).

Could perhaps add some tests to see that it lets "\C-c\C-c" etc through
unscathed... 

> I guess it would also make sense to just change
> `read-kbd-macro' to call kbd, instead of the other way around.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 12 Oct 2021 20:18:20 -0700
> Cc: emacs-devel@gnu.org
> 
> I've attached a quick proof-of-concept of moving the kbd implementation
> to subr.el.  With this, all the tests I have assembled so far pass and
> this bootstraps.  It was mostly just a case of ripping out the calls to
> cl-lib functions.
> 
> If this is something we want to do, I can finish this patch up.

Can we agree that if and when this lands, we will NOT start a deluge
of converting all the key bindings in core to the kbd format?  Let's
agree that, at least as a rule, this is only for new additions to key
bindings, okay?

> -  (should (equal (kbd "C-x a") "\C-xa"))
> +
> +  ;; Modifiers.
> +  (should (equal (kbd "C-x a") "\^Xa"))
> +  (should (equal (kbd "M-x a") [134217848 97]))
> +  (should (equal (kbd "H-x a") [16777336 97]))
> +  (should (equal (kbd "s-x a") [8388728 97]))
> +  (should (equal (kbd "S-x a") [33554552 97]))

Isn't this a bit ad-hoc?  E.g., why did you change the "C-x a" result?

Also, for easier readability and (no less important) write-ability,
how about using this format instead:

  (should (equal (kbd "S-x a") (vector (+ #x2000000 ?x) ?a)))

Thanks.

Re: Moving kbd to subr.el

[Stefan Monnier]

>> +  (should (equal (kbd "M-x a") [134217848 97]))
>> +  (should (equal (kbd "H-x a") [16777336 97]))
>> +  (should (equal (kbd "s-x a") [8388728 97]))
>> +  (should (equal (kbd "S-x a") [33554552 97]))

[?\M-x ?a]
[?\H-x ?a]
[?\s-x ?a]
[?\S-x ?a]


        Stefan

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 607 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
Related: see
https://emacspeak.blogspot.com/2020/10/extracted-light-weight-key-reader-by.html
and some follow-up discussion probably on this list.
>>> +  (should (equal (kbd "M-x a") [134217848 97]))
>>> +  (should (equal (kbd "H-x a") [16777336 97]))
>>> +  (should (equal (kbd "s-x a") [8388728 97]))
>>> +  (should (equal (kbd "S-x a") [33554552 97]))
>
> [?\M-x ?a]
> [?\H-x ?a]
> [?\s-x ?a]
> [?\S-x ?a]
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Stefan Kangas]

T.V Raman <raman@google.com> writes:

> Related: see
> https://emacspeak.blogspot.com/2020/10/extracted-light-weight-key-reader-by.html
> and some follow-up discussion probably on this list.

Thanks, that's useful.  I will most likely "borrow" some ideas from
your tests for the test suite.  There seems to be some opportunities
for simplifying the code as well, something that I avoided in my
version.

Is your 'new-kbd' intended to be bug-for-bug compatible with 'kbd', or
have there been any functional changes along the way?  Are you
suggesting that we could perhaps just replace 'kbd' with your new
version?  (One observation is that your version still uses the cl-
functions, so it would need adjusting for subr.el.)

Re: Moving kbd to subr.el

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> Is your 'new-kbd' intended to be bug-for-bug compatible with 'kbd', or
> have there been any functional changes along the way?  Are you
> suggesting that we could perhaps just replace 'kbd' with your new
> version?  (One observation is that your version still uses the cl-
> functions, so it would need adjusting for subr.el.)

Now I note the following comments:

;;; Tests:
;;; Note that we fail on
;;; "M-ESC"
;;; "M-<DEL>"
;;; "H-<RET>" etc,
;;; But match on "H-RET"
;;; (thanks Drew Adams) Likely due to over-optimization.

So I guess we could borrow ideas from your code but not use it as a
drop-in replacement in its current form.

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1236 bytes --]

Stefan Kangas <stefan@marxist.se> writes:

Yes, you'd  need to fix at least
that documented  incompatibility and likely others; it shows that
writing lots of tests for that function are really important.

If nothing else, rewriting it made the code (at least to me) readable;
the implementation from reading kbd macros was pretty well
incomprehensible at least to my reading of it.


> Stefan Kangas <stefan@marxist.se> writes:
>
>> Is your 'new-kbd' intended to be bug-for-bug compatible with 'kbd', or
>> have there been any functional changes along the way?  Are you
>> suggesting that we could perhaps just replace 'kbd' with your new
>> version?  (One observation is that your version still uses the cl-
>> functions, so it would need adjusting for subr.el.)
>
> Now I note the following comments:
>
> ;;; Tests:
> ;;; Note that we fail on
> ;;; "M-ESC"
> ;;; "M-<DEL>"
> ;;; "H-<RET>" etc,
> ;;; But match on "H-RET"
> ;;; (thanks Drew Adams) Likely due to over-optimization.
>
> So I guess we could borrow ideas from your code but not use it as a
> drop-in replacement in its current form.
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[T.V Raman]

See the associated set of tests -- I intended it to be completely
compatible, but from memory someone on the emacs-devel list pointed
out one diff --
it was an extreme corner case that I didn't fix.

I use ems-kbd in emacspeak instead of  'kbd because it avoids pulling
in all of the keyboard macro code and speeds up startup a bit

Stefan Kangas writes:
 > T.V Raman <raman@google.com> writes:
 > 
 > > Related: see
 > > https://emacspeak.blogspot.com/2020/10/extracted-light-weight-key-reader-by.html
 > > and some follow-up discussion probably on this list.
 > 
 > Thanks, that's useful.  I will most likely "borrow" some ideas from
 > your tests for the test suite.  There seems to be some opportunities
 > for simplifying the code as well, something that I avoided in my
 > version.
 > 
 > Is your 'new-kbd' intended to be bug-for-bug compatible with 'kbd', or
 > have there been any functional changes along the way?  Are you
 > suggesting that we could perhaps just replace 'kbd' with your new
 > version?  (One observation is that your version still uses the cl-
 > functions, so it would need adjusting for subr.el.)

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Moving kbd to subr.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > If this is something we want to do, I can finish this patch up.
>
> Can we agree that if and when this lands, we will NOT start a deluge
> of converting all the key bindings in core to the kbd format?  Let's
> agree that, at least as a rule, this is only for new additions to key
> bindings, okay?

Yeah, I don't think converting them en masse sounds worth doing.  It
needs care in every case, and specific testing, or you will risk
introducing bugs.

> > -  (should (equal (kbd "C-x a") "\C-xa"))
> > +
> > +  ;; Modifiers.
> > +  (should (equal (kbd "C-x a") "\^Xa"))
> > +  (should (equal (kbd "M-x a") [134217848 97]))
> > +  (should (equal (kbd "H-x a") [16777336 97]))
> > +  (should (equal (kbd "s-x a") [8388728 97]))
> > +  (should (equal (kbd "S-x a") [33554552 97]))
>
> Isn't this a bit ad-hoc?  E.g., why did you change the "C-x a" result?

I don't think I see what has changed.  This is what I get in Emacs 27.2:

    (kbd "C-x a")
    " ^Xa"

If I did my job right, nothing will have changed as this should just
be a straight conversion from CL-Lib to ELisp.  I might have made a
mistake somewhere, of course, and as I said I didn't look it over for
correctness in much detail yet.

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 13 Oct 2021 14:50:12 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Emacs developers <emacs-devel@gnu.org>
> > > -  (should (equal (kbd "C-x a") "\C-xa"))
> > > +
> > > +  ;; Modifiers.
> > > +  (should (equal (kbd "C-x a") "\^Xa"))
> > > +  (should (equal (kbd "M-x a") [134217848 97]))
> > > +  (should (equal (kbd "H-x a") [16777336 97]))
> > > +  (should (equal (kbd "s-x a") [8388728 97]))
> > > +  (should (equal (kbd "S-x a") [33554552 97]))
> >
> > Isn't this a bit ad-hoc?  E.g., why did you change the "C-x a" result?
> 
> I don't think I see what has changed.  This is what I get in Emacs 27.2:
> 
>     (kbd "C-x a")
>     " ^Xa"

I didn't say anything has changed, I asked why you didn't leave the
original "C-x a" intact.

> If I did my job right, nothing will have changed as this should just
> be a straight conversion from CL-Lib to ELisp.  I might have made a
> mistake somewhere, of course, and as I said I didn't look it over for
> correctness in much detail yet.

Precisely because there could be mistakes, we should not adapt what
should happen to what did happen, we should keep the previous results
where we had them.

Re: Moving kbd to subr.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't say anything has changed, I asked why you didn't leave the
> original "C-x a" intact.

Ah, now I see what you mean.  No reason, it just happened that way as
I wrote this patch up rather quickly.  I'll revert to the old form as
there's no reason to change it.

> Precisely because there could be mistakes, we should not adapt what
> should happen to what did happen, we should keep the previous results
> where we had them.

If I understand you correctly, you are saying that we want kbd to
behave in exactly the same way as before.  I very much agree, there
should be no functional change (a.k.a. bug for bug compatibility).
The method I see for ensuring that is to develop all tests using the
old version of kbd (I use Emacs 27.2 for testing) and then make sure
that the new code passes the same tests.

Re: Moving kbd to subr.el

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

Stefan Kangas <stefankangas@gmail.com> writes:

> I've attached a quick proof-of-concept of moving the kbd implementation
> to subr.el.  With this, all the tests I have assembled so far pass and
> this bootstraps.  It was mostly just a case of ripping out the calls to
> cl-lib functions.

Here's an updated version of this, that bootstraps like before.  Besides
studying the code more closely to convince myself that it's doing the
same thing as before, I've also pushed a more complete test suite for
'kbd' and 'edmacro-parse-keys' to master.  Thanks to everyone who
commented on the first version of this patch and helped with the tests.

This patch (hopefully) brings no functional changes, and so should not
really need any update of any documentation, unless it was in some way
already lacking before.  The only difference here should be that we can
now use `kbd' in preloaded code.

---

There is one snag in the way this has always worked: 'kbd' currently
supports everything that 'edmacro-parse-keys' does, including this part:

     * Double angle brackets enclose command names:  <<next-line>> is
       shorthand for M-x next-line RET.

     * Finally, REM or ;; causes the rest of the line to be ignored as a
       comment.

    Any word may be prefixed by a multiplier in the form of a decimal
    number and ‘*’:  3*<right> = <right> <right> <right>, and
    10*foo = foofoofoofoofoofoofoofoofoofoo.

This does not seem to make sense when it comes to using `kbd' for
keybindings.

However, I guess this has not been a problem over the years, and should
better be left alone: maybe some users are relying on it at this point.
I mostly just wanted to bring it to everyone's attention.

[-- Attachment #2: 0001-Make-kbd-usable-during-bootstrap.patch --]
[-- Type: text/x-diff, Size: 6927 bytes --]

From e732aed70f61b6822f37987312d55b8d6a0be223 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 13 Oct 2021 01:40:14 +0200
Subject: [PATCH 1/2] Make kbd usable during bootstrap

* lisp/subr.el (kbd): Make kbd usable during bootstrap by copying the
definition of 'read-kbd-macro' into it, and adjusting it to no longer
use CL-Lib functions.
---
 lisp/subr.el | 110 +++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 107 insertions(+), 3 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index a1858e5911..1c3dc26a4d 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -933,11 +933,115 @@ kbd
 `edmacro-mode').
 
 For an approximate inverse of this, see `key-description'."
-  ;; Don't use a defalias, since the `pure' property is true only for
-  ;; the calling convention of `kbd'.
   (declare (pure t) (side-effect-free t))
   ;; A pure function is expected to preserve the match data.
-  (save-match-data (read-kbd-macro keys)))
+  (save-match-data
+    (let ((case-fold-search nil)
+          (len (length keys)) ; We won't alter keys in the loop below.
+          (pos 0)
+          (res []))
+      (while (and (< pos len)
+                  (string-match "[^ \t\n\f]+" keys pos))
+        (let* ((word-beg (match-beginning 0))
+               (word-end (match-end 0))
+               (word (substring keys word-beg len))
+               (times 1)
+               key)
+          ;; Try to catch events of the form "<as df>".
+          (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
+              (setq word (match-string 0 word)
+                    pos (+ word-beg (match-end 0)))
+            (setq word (substring keys word-beg word-end)
+                  pos word-end))
+          (when (string-match "\\([0-9]+\\)\\*." word)
+            (setq times (string-to-number (substring word 0 (match-end 1))))
+            (setq word (substring word (1+ (match-end 1)))))
+          (cond ((string-match "^<<.+>>$" word)
+                 (setq key (vconcat (if (eq (key-binding [?\M-x])
+                                            'execute-extended-command)
+                                        [?\M-x]
+                                      (or (car (where-is-internal
+                                                'execute-extended-command))
+                                          [?\M-x]))
+                                    (substring word 2 -2) "\r")))
+                ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
+                      (progn
+                        (setq word (concat (match-string 1 word)
+                                           (match-string 3 word)))
+                        (not (string-match
+                              "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
+                              word))))
+                 (setq key (list (intern word))))
+                ((or (equal word "REM") (string-match "^;;" word))
+                 (setq pos (string-match "$" keys pos)))
+                (t
+                 (let ((orig-word word) (prefix 0) (bits 0))
+                   (while (string-match "^[ACHMsS]-." word)
+                     (setq bits (+ bits (cdr (assq (aref word 0)
+                                                   '((?A . ?\A-\^@) (?C . ?\C-\^@)
+                                                     (?H . ?\H-\^@) (?M . ?\M-\^@)
+                                                     (?s . ?\s-\^@) (?S . ?\S-\^@))))))
+                     (setq prefix (+ prefix 2))
+                     (setq word (substring word 2)))
+                   (when (string-match "^\\^.$" word)
+                     (setq bits (+ bits ?\C-\^@))
+                     (setq prefix (1+ prefix))
+                     (setq word (substring word 1)))
+                   (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
+                                              ("LFD" . "\n") ("TAB" . "\t")
+                                              ("ESC" . "\e") ("SPC" . " ")
+                                              ("DEL" . "\177")))))
+                     (when found (setq word (cdr found))))
+                   (when (string-match "^\\\\[0-7]+$" word)
+                     (let ((n 0))
+                       (dolist (ch (cdr (string-to-list word)))
+                         (setq n (+ (* n 8) ch -48)))
+                       (setq word (vector n))))
+                   (cond ((= bits 0)
+                          (setq key word))
+                         ((and (= bits ?\M-\^@) (stringp word)
+                               (string-match "^-?[0-9]+$" word))
+                          (setq key (mapcar (lambda (x) (+ x bits))
+                                            (append word nil))))
+                         ((/= (length word) 1)
+                          (error "%s must prefix a single character, not %s"
+                                 (substring orig-word 0 prefix) word))
+                         ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
+                               ;; We used to accept . and ? here,
+                               ;; but . is simply wrong,
+                               ;; and C-? is not used (we use DEL instead).
+                               (string-match "[@-_a-z]" word))
+                          (setq key (list (+ bits (- ?\C-\^@)
+                                             (logand (aref word 0) 31)))))
+                         (t
+                          (setq key (list (+ bits (aref word 0)))))))))
+          (when key
+            (dolist (_ (number-sequence 1 times))
+              (setq res (vconcat res key))))))
+      (when (and (>= (length res) 4)
+                 (eq (aref res 0) ?\C-x)
+                 (eq (aref res 1) ?\()
+                 (eq (aref res (- (length res) 2)) ?\C-x)
+                 (eq (aref res (- (length res) 1)) ?\)))
+        (setq res (apply #'vector (let ((lres (append res nil)))
+                                    ;; Remove the first and last two elements.
+                                    (setq lres (cdr (cdr lres)))
+                                    (nreverse lres)
+                                    (setq lres (cdr (cdr lres)))
+                                    (nreverse lres)
+                                    lres))))
+      (if (let ((ret t))
+            (dolist (ch (append res nil))
+              (unless (and (characterp ch)
+                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                             (and (>= ch2 0) (<= ch2 127))))
+                (setq ret nil)))
+            ret)
+          (concat (mapcar (lambda (ch)
+                            (if (= (logand ch ?\M-\^@) 0)
+                                ch (+ ch 128)))
+                          (append res nil)))
+        res))))
 
 (defun undefined ()
   "Beep to tell the user this binding is undefined."
-- 
2.30.2


[-- Attachment #3: 0002-Remove-duplicate-code-in-edmacro-parse-keys.patch --]
[-- Type: text/x-diff, Size: 8717 bytes --]

From a1eec2ae1727c3fa6ccdceb3c74e22903f7d558d Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 13 Oct 2021 22:54:47 +0200
Subject: [PATCH 2/2] Remove duplicate code in edmacro-parse-keys

* 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'.
---
 lisp/edmacro.el | 96 +------------------------------------------------
 lisp/subr.el    | 46 ++++++++++++++----------
 2 files changed, 28 insertions(+), 114 deletions(-)

diff --git a/lisp/edmacro.el b/lisp/edmacro.el
index a4eb574a4c..5f8780847c 100644
--- a/lisp/edmacro.el
+++ b/lisp/edmacro.el
@@ -640,101 +640,7 @@ edmacro-fix-menu-commands
 ;;; Parsing a human-readable keyboard macro.
 
 (defun edmacro-parse-keys (string &optional need-vector)
-  (let ((case-fold-search nil)
-	(len (length string)) ; We won't alter string in the loop below.
-	(pos 0)
-	(res []))
-    (while (and (< pos len)
-		(string-match "[^ \t\n\f]+" string pos))
-      (let* ((word-beg (match-beginning 0))
-	     (word-end (match-end 0))
-	     (word (substring string word-beg len))
-	     (times 1)
-	     key)
-	;; Try to catch events of the form "<as df>".
-	(if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
-	    (setq word (match-string 0 word)
-		  pos (+ word-beg (match-end 0)))
-	  (setq word (substring string word-beg word-end)
-		pos word-end))
-	(when (string-match "\\([0-9]+\\)\\*." word)
-	  (setq times (string-to-number (substring word 0 (match-end 1))))
-	  (setq word (substring word (1+ (match-end 1)))))
-	(cond ((string-match "^<<.+>>$" word)
-	       (setq key (vconcat (if (eq (key-binding [?\M-x])
-					  'execute-extended-command)
-				      [?\M-x]
-				    (or (car (where-is-internal
-					      'execute-extended-command))
-					[?\M-x]))
-				  (substring word 2 -2) "\r")))
-	      ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
-		    (progn
-		      (setq word (concat (match-string 1 word)
-					 (match-string 3 word)))
-		      (not (string-match
-			    "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
-			    word))))
-	       (setq key (list (intern word))))
-	      ((or (equal word "REM") (string-match "^;;" word))
-	       (setq pos (string-match "$" string pos)))
-	      (t
-	       (let ((orig-word word) (prefix 0) (bits 0))
-		 (while (string-match "^[ACHMsS]-." word)
-		   (cl-incf bits (cdr (assq (aref word 0)
-					 '((?A . ?\A-\^@) (?C . ?\C-\^@)
-					   (?H . ?\H-\^@) (?M . ?\M-\^@)
-					   (?s . ?\s-\^@) (?S . ?\S-\^@)))))
-		   (cl-incf prefix 2)
-		   (cl-callf substring word 2))
-		 (when (string-match "^\\^.$" word)
-		   (cl-incf bits ?\C-\^@)
-		   (cl-incf prefix)
-		   (cl-callf substring word 1))
-		 (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
-					    ("LFD" . "\n") ("TAB" . "\t")
-					    ("ESC" . "\e") ("SPC" . " ")
-					    ("DEL" . "\177")))))
-		   (when found (setq word (cdr found))))
-		 (when (string-match "^\\\\[0-7]+$" word)
-		   (cl-loop for ch across word
-                            for n = 0 then (+ (* n 8) ch -48)
-                            finally do (setq word (vector n))))
-		 (cond ((= bits 0)
-			(setq key word))
-		       ((and (= bits ?\M-\^@) (stringp word)
-			     (string-match "^-?[0-9]+$" word))
-			(setq key (cl-loop for x across word
-                                           collect (+ x bits))))
-		       ((/= (length word) 1)
-			(error "%s must prefix a single character, not %s"
-			       (substring orig-word 0 prefix) word))
-		       ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
-			     ;; We used to accept . and ? here,
-			     ;; but . is simply wrong,
-			     ;; and C-? is not used (we use DEL instead).
-			     (string-match "[@-_a-z]" word))
-			(setq key (list (+ bits (- ?\C-\^@)
-					   (logand (aref word 0) 31)))))
-		       (t
-			(setq key (list (+ bits (aref word 0)))))))))
-	(when key
-	  (cl-loop repeat times do (cl-callf vconcat res key)))))
-    (when (and (>= (length res) 4)
-	       (eq (aref res 0) ?\C-x)
-	       (eq (aref res 1) ?\()
-	       (eq (aref res (- (length res) 2)) ?\C-x)
-	       (eq (aref res (- (length res) 1)) ?\)))
-      (setq res (cl-subseq res 2 -2)))
-    (if (and (not need-vector)
-	     (cl-loop for ch across res
-                      always (and (characterp ch)
-                                  (let ((ch2 (logand ch (lognot ?\M-\^@))))
-                                    (and (>= ch2 0) (<= ch2 127))))))
-	(concat (cl-loop for ch across res
-                         collect (if (= (logand ch ?\M-\^@) 0)
-                                     ch (+ ch 128))))
-      res)))
+  (internal--kbd string need-vector))
 
 (provide 'edmacro)
 
diff --git a/lisp/subr.el b/lisp/subr.el
index 1c3dc26a4d..812ae962b7 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -925,33 +925,29 @@ remq
 \f
 ;;;; Keymap support.
 
-(defun kbd (keys)
+(defun internal--kbd (string &optional need-vector)
   "Convert KEYS to the internal Emacs key representation.
-KEYS should be a string in the format returned by commands such
-as `C-h k' (`describe-key').
-This is the same format used for saving keyboard macros (see
-`edmacro-mode').
-
-For an approximate inverse of this, see `key-description'."
+This is an internal function, and should not be used directly.
+See instead `kbd'."
   (declare (pure t) (side-effect-free t))
   ;; A pure function is expected to preserve the match data.
   (save-match-data
     (let ((case-fold-search nil)
-          (len (length keys)) ; We won't alter keys in the loop below.
+          (len (length string)) ; We won't alter string in the loop below.
           (pos 0)
           (res []))
       (while (and (< pos len)
-                  (string-match "[^ \t\n\f]+" keys pos))
+                  (string-match "[^ \t\n\f]+" string pos))
         (let* ((word-beg (match-beginning 0))
                (word-end (match-end 0))
-               (word (substring keys word-beg len))
+               (word (substring string word-beg len))
                (times 1)
                key)
           ;; Try to catch events of the form "<as df>".
           (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
               (setq word (match-string 0 word)
                     pos (+ word-beg (match-end 0)))
-            (setq word (substring keys word-beg word-end)
+            (setq word (substring string word-beg word-end)
                   pos word-end))
           (when (string-match "\\([0-9]+\\)\\*." word)
             (setq times (string-to-number (substring word 0 (match-end 1))))
@@ -973,7 +969,7 @@ kbd
                               word))))
                  (setq key (list (intern word))))
                 ((or (equal word "REM") (string-match "^;;" word))
-                 (setq pos (string-match "$" keys pos)))
+                 (setq pos (string-match "$" string pos)))
                 (t
                  (let ((orig-word word) (prefix 0) (bits 0))
                    (while (string-match "^[ACHMsS]-." word)
@@ -1030,19 +1026,31 @@ kbd
                                     (setq lres (cdr (cdr lres)))
                                     (nreverse lres)
                                     lres))))
-      (if (let ((ret t))
-            (dolist (ch (append res nil))
-              (unless (and (characterp ch)
-                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
-                             (and (>= ch2 0) (<= ch2 127))))
-                (setq ret nil)))
-            ret)
+      (if (and (not need-vector)
+               (let ((ret t))
+                 (dolist (ch (append res nil))
+                   (unless (and (characterp ch)
+                                (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                                  (and (>= ch2 0) (<= ch2 127))))
+                     (setq ret nil)))
+                 ret))
           (concat (mapcar (lambda (ch)
                             (if (= (logand ch ?\M-\^@) 0)
                                 ch (+ ch 128)))
                           (append res nil)))
         res))))
 
+(defun kbd (keys)
+  "Convert KEYS to the internal Emacs key representation.
+KEYS should be a string in the format returned by commands such
+as `C-h k' (`describe-key').
+This is the same format used for saving keyboard macros (see
+`edmacro-mode').
+
+For an approximate inverse of this, see `key-description'."
+  (declare (pure t) (side-effect-free t))
+  (internal--kbd keys))
+
 (defun undefined ()
   "Beep to tell the user this binding is undefined."
   (declare (completion ignore))
-- 
2.30.2

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> This patch (hopefully) brings no functional changes, and so should not
> really need any update of any documentation, unless it was in some way
> already lacking before.  The only difference here should be that we can
> now use `kbd' in preloaded code.

Great!

And this reminds me -- perhaps we can add a `byte-optimizer' thingie to
`kbd' to make it expand the argument at compile time (if the parameter
is a literal string)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And this reminds me -- perhaps we can add a `byte-optimizer' thingie to
> `kbd' to make it expand the argument at compile time (if the parameter
> is a literal string)?

Should have checked first -- that's already done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 13 Oct 2021 15:28:36 -0700
> Cc: emacs-devel@gnu.org
> 
> From e732aed70f61b6822f37987312d55b8d6a0be223 Mon Sep 17 00:00:00 2001
> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 13 Oct 2021 01:40:14 +0200
> Subject: [PATCH 1/2] Make kbd usable during bootstrap
> 
> * lisp/subr.el (kbd): Make kbd usable during bootstrap by copying the

Please quote the 2nd instance of "kbd".

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

No NEWS entry?

> * 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?

> +(defun internal--kbd (string &optional need-vector)
>    "Convert KEYS to the internal Emacs key representation.
> -KEYS should be a string in the format returned by commands such
> -as `C-h k' (`describe-key').
> -This is the same format used for saving keyboard macros (see
> -`edmacro-mode').
> -
> -For an approximate inverse of this, see `key-description'."
> +This is an internal function, and should not be used directly.
> +See instead `kbd'."
   ^^^^^^^^^^^^^^^^^
This sounds awkward.  Why not "Use `kbd' instead."?

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'.

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 14 Oct 2021 04:50:31 -0700
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> > 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.

Using kbd no longer needs to require edmacro, so it isn't entirely
internal.

> > 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'.

That sounds less clean than I'd like it to be, FWIW.  Having a trivial
wrapper in our own code just to avoid an optional argument?

Lars, WDYT?

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Using kbd no longer needs to require edmacro, so it isn't entirely
> internal.

A NEWS entry saying "kbd can be used in built-in files" would be nice,
perhaps? 

> That sounds less clean than I'd like it to be, FWIW.  Having a trivial
> wrapper in our own code just to avoid an optional argument?
>
> Lars, WDYT?

Yeah, I think kbd could just take the optional parameter.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> A NEWS entry saying "kbd can be used in built-in files" would be nice,
> perhaps?

Sure, I'm happy to add that.

> Yeah, I think kbd could just take the optional parameter.

OK, let's do that.  Please see the attached updated patch.

(If we really wanted to not have the parameter, I suppose we could use
`set-advertised-calling-convention' and `with-suppressed-warnings' but
that might be too much of a hack.)

[-- Attachment #2: 0001-Make-kbd-usable-during-bootstrap.patch --]
[-- Type: text/x-diff, Size: 7503 bytes --]

From 2424a213e79940eae9dd6c0f612590c3d309a1da Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 13 Oct 2021 01:40:14 +0200
Subject: [PATCH 1/2] Make kbd usable during bootstrap

* lisp/subr.el (kbd): Make 'kbd' usable during bootstrap by copying
the definition of 'read-kbd-macro' into it, and adjusting it to no
longer use CL-Lib functions.

This change is discussed in
https://lists.gnu.org/r/emacs-devel/2021-10/msg00909.html
---
 etc/NEWS     |   4 ++
 lisp/subr.el | 110 +++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 7dd4d14274..9412c62aa4 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -189,6 +189,10 @@ This function allows defining a number of keystrokes with one form.
 ** New macro 'defvar-keymap'.
 This macro allows defining keymap variables more conveniently.
 
+---
+** 'kbd' can now be used in built-in, preloaded libraries.
+It no longer depends on edmacro.el and cl-lib.el.
+
 \f
 * Changes in Emacs 29.1 on Non-Free Operating Systems
 
diff --git a/lisp/subr.el b/lisp/subr.el
index a1858e5911..1c3dc26a4d 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -933,11 +933,115 @@ kbd
 `edmacro-mode').
 
 For an approximate inverse of this, see `key-description'."
-  ;; Don't use a defalias, since the `pure' property is true only for
-  ;; the calling convention of `kbd'.
   (declare (pure t) (side-effect-free t))
   ;; A pure function is expected to preserve the match data.
-  (save-match-data (read-kbd-macro keys)))
+  (save-match-data
+    (let ((case-fold-search nil)
+          (len (length keys)) ; We won't alter keys in the loop below.
+          (pos 0)
+          (res []))
+      (while (and (< pos len)
+                  (string-match "[^ \t\n\f]+" keys pos))
+        (let* ((word-beg (match-beginning 0))
+               (word-end (match-end 0))
+               (word (substring keys word-beg len))
+               (times 1)
+               key)
+          ;; Try to catch events of the form "<as df>".
+          (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
+              (setq word (match-string 0 word)
+                    pos (+ word-beg (match-end 0)))
+            (setq word (substring keys word-beg word-end)
+                  pos word-end))
+          (when (string-match "\\([0-9]+\\)\\*." word)
+            (setq times (string-to-number (substring word 0 (match-end 1))))
+            (setq word (substring word (1+ (match-end 1)))))
+          (cond ((string-match "^<<.+>>$" word)
+                 (setq key (vconcat (if (eq (key-binding [?\M-x])
+                                            'execute-extended-command)
+                                        [?\M-x]
+                                      (or (car (where-is-internal
+                                                'execute-extended-command))
+                                          [?\M-x]))
+                                    (substring word 2 -2) "\r")))
+                ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
+                      (progn
+                        (setq word (concat (match-string 1 word)
+                                           (match-string 3 word)))
+                        (not (string-match
+                              "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
+                              word))))
+                 (setq key (list (intern word))))
+                ((or (equal word "REM") (string-match "^;;" word))
+                 (setq pos (string-match "$" keys pos)))
+                (t
+                 (let ((orig-word word) (prefix 0) (bits 0))
+                   (while (string-match "^[ACHMsS]-." word)
+                     (setq bits (+ bits (cdr (assq (aref word 0)
+                                                   '((?A . ?\A-\^@) (?C . ?\C-\^@)
+                                                     (?H . ?\H-\^@) (?M . ?\M-\^@)
+                                                     (?s . ?\s-\^@) (?S . ?\S-\^@))))))
+                     (setq prefix (+ prefix 2))
+                     (setq word (substring word 2)))
+                   (when (string-match "^\\^.$" word)
+                     (setq bits (+ bits ?\C-\^@))
+                     (setq prefix (1+ prefix))
+                     (setq word (substring word 1)))
+                   (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
+                                              ("LFD" . "\n") ("TAB" . "\t")
+                                              ("ESC" . "\e") ("SPC" . " ")
+                                              ("DEL" . "\177")))))
+                     (when found (setq word (cdr found))))
+                   (when (string-match "^\\\\[0-7]+$" word)
+                     (let ((n 0))
+                       (dolist (ch (cdr (string-to-list word)))
+                         (setq n (+ (* n 8) ch -48)))
+                       (setq word (vector n))))
+                   (cond ((= bits 0)
+                          (setq key word))
+                         ((and (= bits ?\M-\^@) (stringp word)
+                               (string-match "^-?[0-9]+$" word))
+                          (setq key (mapcar (lambda (x) (+ x bits))
+                                            (append word nil))))
+                         ((/= (length word) 1)
+                          (error "%s must prefix a single character, not %s"
+                                 (substring orig-word 0 prefix) word))
+                         ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
+                               ;; We used to accept . and ? here,
+                               ;; but . is simply wrong,
+                               ;; and C-? is not used (we use DEL instead).
+                               (string-match "[@-_a-z]" word))
+                          (setq key (list (+ bits (- ?\C-\^@)
+                                             (logand (aref word 0) 31)))))
+                         (t
+                          (setq key (list (+ bits (aref word 0)))))))))
+          (when key
+            (dolist (_ (number-sequence 1 times))
+              (setq res (vconcat res key))))))
+      (when (and (>= (length res) 4)
+                 (eq (aref res 0) ?\C-x)
+                 (eq (aref res 1) ?\()
+                 (eq (aref res (- (length res) 2)) ?\C-x)
+                 (eq (aref res (- (length res) 1)) ?\)))
+        (setq res (apply #'vector (let ((lres (append res nil)))
+                                    ;; Remove the first and last two elements.
+                                    (setq lres (cdr (cdr lres)))
+                                    (nreverse lres)
+                                    (setq lres (cdr (cdr lres)))
+                                    (nreverse lres)
+                                    lres))))
+      (if (let ((ret t))
+            (dolist (ch (append res nil))
+              (unless (and (characterp ch)
+                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                             (and (>= ch2 0) (<= ch2 127))))
+                (setq ret nil)))
+            ret)
+          (concat (mapcar (lambda (ch)
+                            (if (= (logand ch ?\M-\^@) 0)
+                                ch (+ ch 128)))
+                          (append res nil)))
+        res))))
 
 (defun undefined ()
   "Beep to tell the user this binding is undefined."
-- 
2.30.2


[-- Attachment #3: 0002-Remove-duplicate-code-in-edmacro-parse-keys.patch --]
[-- Type: text/x-diff, Size: 6734 bytes --]

From cdafa2120e5dd52ea4db0620f81fe7181c33f9a8 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 13 Oct 2021 22:54:47 +0200
Subject: [PATCH 2/2] Remove duplicate code in edmacro-parse-keys

* lisp/subr.el (kbd): Add argument NEED-VECTOR and make it suitable
for calling from 'edmacro-parse-keys'.
* lisp/edmacro.el (edmacro-parse-keys): Replace definition with a
call to 'kbd'.

This change is discussed in
https://lists.gnu.org/r/emacs-devel/2021-10/msg00909.html
---
 lisp/edmacro.el | 96 +------------------------------------------------
 lisp/subr.el    | 23 +++++++-----
 2 files changed, 15 insertions(+), 104 deletions(-)

diff --git a/lisp/edmacro.el b/lisp/edmacro.el
index a4eb574a4c..decb8edbb1 100644
--- a/lisp/edmacro.el
+++ b/lisp/edmacro.el
@@ -640,101 +640,7 @@ edmacro-fix-menu-commands
 ;;; Parsing a human-readable keyboard macro.
 
 (defun edmacro-parse-keys (string &optional need-vector)
-  (let ((case-fold-search nil)
-	(len (length string)) ; We won't alter string in the loop below.
-	(pos 0)
-	(res []))
-    (while (and (< pos len)
-		(string-match "[^ \t\n\f]+" string pos))
-      (let* ((word-beg (match-beginning 0))
-	     (word-end (match-end 0))
-	     (word (substring string word-beg len))
-	     (times 1)
-	     key)
-	;; Try to catch events of the form "<as df>".
-	(if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
-	    (setq word (match-string 0 word)
-		  pos (+ word-beg (match-end 0)))
-	  (setq word (substring string word-beg word-end)
-		pos word-end))
-	(when (string-match "\\([0-9]+\\)\\*." word)
-	  (setq times (string-to-number (substring word 0 (match-end 1))))
-	  (setq word (substring word (1+ (match-end 1)))))
-	(cond ((string-match "^<<.+>>$" word)
-	       (setq key (vconcat (if (eq (key-binding [?\M-x])
-					  'execute-extended-command)
-				      [?\M-x]
-				    (or (car (where-is-internal
-					      'execute-extended-command))
-					[?\M-x]))
-				  (substring word 2 -2) "\r")))
-	      ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
-		    (progn
-		      (setq word (concat (match-string 1 word)
-					 (match-string 3 word)))
-		      (not (string-match
-			    "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
-			    word))))
-	       (setq key (list (intern word))))
-	      ((or (equal word "REM") (string-match "^;;" word))
-	       (setq pos (string-match "$" string pos)))
-	      (t
-	       (let ((orig-word word) (prefix 0) (bits 0))
-		 (while (string-match "^[ACHMsS]-." word)
-		   (cl-incf bits (cdr (assq (aref word 0)
-					 '((?A . ?\A-\^@) (?C . ?\C-\^@)
-					   (?H . ?\H-\^@) (?M . ?\M-\^@)
-					   (?s . ?\s-\^@) (?S . ?\S-\^@)))))
-		   (cl-incf prefix 2)
-		   (cl-callf substring word 2))
-		 (when (string-match "^\\^.$" word)
-		   (cl-incf bits ?\C-\^@)
-		   (cl-incf prefix)
-		   (cl-callf substring word 1))
-		 (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
-					    ("LFD" . "\n") ("TAB" . "\t")
-					    ("ESC" . "\e") ("SPC" . " ")
-					    ("DEL" . "\177")))))
-		   (when found (setq word (cdr found))))
-		 (when (string-match "^\\\\[0-7]+$" word)
-		   (cl-loop for ch across word
-                            for n = 0 then (+ (* n 8) ch -48)
-                            finally do (setq word (vector n))))
-		 (cond ((= bits 0)
-			(setq key word))
-		       ((and (= bits ?\M-\^@) (stringp word)
-			     (string-match "^-?[0-9]+$" word))
-			(setq key (cl-loop for x across word
-                                           collect (+ x bits))))
-		       ((/= (length word) 1)
-			(error "%s must prefix a single character, not %s"
-			       (substring orig-word 0 prefix) word))
-		       ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
-			     ;; We used to accept . and ? here,
-			     ;; but . is simply wrong,
-			     ;; and C-? is not used (we use DEL instead).
-			     (string-match "[@-_a-z]" word))
-			(setq key (list (+ bits (- ?\C-\^@)
-					   (logand (aref word 0) 31)))))
-		       (t
-			(setq key (list (+ bits (aref word 0)))))))))
-	(when key
-	  (cl-loop repeat times do (cl-callf vconcat res key)))))
-    (when (and (>= (length res) 4)
-	       (eq (aref res 0) ?\C-x)
-	       (eq (aref res 1) ?\()
-	       (eq (aref res (- (length res) 2)) ?\C-x)
-	       (eq (aref res (- (length res) 1)) ?\)))
-      (setq res (cl-subseq res 2 -2)))
-    (if (and (not need-vector)
-	     (cl-loop for ch across res
-                      always (and (characterp ch)
-                                  (let ((ch2 (logand ch (lognot ?\M-\^@))))
-                                    (and (>= ch2 0) (<= ch2 127))))))
-	(concat (cl-loop for ch across res
-                         collect (if (= (logand ch ?\M-\^@) 0)
-                                     ch (+ ch 128))))
-      res)))
+  (kbd string need-vector))
 
 (provide 'edmacro)
 
diff --git a/lisp/subr.el b/lisp/subr.el
index 1c3dc26a4d..93ec76e290 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -925,14 +925,18 @@ remq
 \f
 ;;;; Keymap support.
 
-(defun kbd (keys)
+(defun kbd (keys &optional need-vector)
   "Convert KEYS to the internal Emacs key representation.
 KEYS should be a string in the format returned by commands such
 as `C-h k' (`describe-key').
 This is the same format used for saving keyboard macros (see
 `edmacro-mode').
 
-For an approximate inverse of this, see `key-description'."
+For an approximate inverse of this, see `key-description'.
+
+If NEED-VECTOR is non-nil, always return a vector instead of a
+string.  This is mainly intended for use by `edmacro-parse-keys',
+and should normally not be needed."
   (declare (pure t) (side-effect-free t))
   ;; A pure function is expected to preserve the match data.
   (save-match-data
@@ -1030,13 +1034,14 @@ kbd
                                     (setq lres (cdr (cdr lres)))
                                     (nreverse lres)
                                     lres))))
-      (if (let ((ret t))
-            (dolist (ch (append res nil))
-              (unless (and (characterp ch)
-                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
-                             (and (>= ch2 0) (<= ch2 127))))
-                (setq ret nil)))
-            ret)
+      (if (and (not need-vector)
+               (let ((ret t))
+                 (dolist (ch (append res nil))
+                   (unless (and (characterp ch)
+                                (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                                  (and (>= ch2 0) (<= ch2 127))))
+                     (setq ret nil)))
+                 ret))
           (concat (mapcar (lambda (ch)
                             (if (= (logand ch ?\M-\^@) 0)
                                 ch (+ ch 128)))
-- 
2.30.2

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Yeah, I think kbd could just take the optional parameter.
>
> OK, let's do that.  Please see the attached updated patch.

Looks good to me, but reading this patch again -- couldn't
edmacro-parse-keys just convert the result (if it's a string) to a
vector if it wants that?
  
-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Looks good to me, but reading this patch again -- couldn't
> edmacro-parse-keys just convert the result (if it's a string) to a
> vector if it wants that?

Do you mean converting the vector to a string in kbd unconditionally,
and then add code to edmacro-parse-keys to convert it back to a vector?
I guess we could do that, but doesn't it seem like a rather strange
dance?

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Do you mean converting the vector to a string in kbd unconditionally,
> and then add code to edmacro-parse-keys to convert it back to a vector?

No, just have kbd return a string or a vector according to how it
behaves now, but if edmacro wants to return a vector, then it converts
the result to a vector (if it got a string).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, just have kbd return a string or a vector according to how it
> behaves now, but if edmacro wants to return a vector, then it converts
> the result to a vector (if it got a string).

OK, so looking even closer at this to develop test cases for the above,
in the original code we have this convoluted mess:

(if (and (not need-vector)
         (cl-loop for ch across res
                  always (and (characterp ch)
                              (let ((ch2 (logand ch (lognot ?\M-\^@))))
                                (and (>= ch2 0) (<= ch2 127))))))
    (concat (cl-loop for ch across res
                     collect (if (= (logand ch ?\M-\^@) 0)
                                 ch (+ ch 128))))
  res)

Given that characterp comes down to

    return 0 <= c && c <= MAX_CHAR; // MAX_CHAR = 0x3FFFFF

and that ?\M-\^@ is #x8000000, the `and' clause here simplifies to:

    (and (<= 0 ch #x3fffff)
         (<= 0 (logand ch (lognot #x8000000)) 127))

But that is equivalent to:

    (<= 0 ch 127)

Right?  So what is this code actually supposed to do?

Currently, I'm a bit stomped as in any test case I can think of,
including all tests in the test suite, kbd and edmacro-parse-keys
behaves exactly the same in Emacs 27.2.  Can anyone think of a test case
where they won't?

BTW, you can verify the above simplification for yourself using:

(let ((ch 0) accum)
  (while (< ch #xFFFFFFF)
    (when (and (characterp ch)
	       (let ((ch2 (logand ch (lognot ?\M-\^@))))
		 (and (>= ch2 0) (<= ch2 127))))
      (push ch accum))
    (setq ch (1+ ch)))
  (let ((standard-output (current-buffer)))
    (princ accum)))

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> OK, so looking even closer at this to develop test cases for the above,
> in the original code we have this convoluted mess:
>
> (if (and (not need-vector)
>          (cl-loop for ch across res
>                   always (and (characterp ch)
>                               (let ((ch2 (logand ch (lognot ?\M-\^@))))
>                                 (and (>= ch2 0) (<= ch2 127))))))
>     (concat (cl-loop for ch across res
>                      collect (if (= (logand ch ?\M-\^@) 0)
>                                  ch (+ ch 128))))
>   res)

Yeah, my eyes glazed over when reading that code the first few times.
:-) 

> But that is equivalent to:
>
>     (<= 0 ch 127)

I think...  you're totally right.  It looks like a very convoluted way
to write (<= 0 ch 127).

But perhaps there's historical reasons for the code being that way?  In
the olden days, Emacs didn't use utf-8 as the character representation,
so perhaps it made sense back then?  (I don't actually recall how
characters were represented in that Mule era.)

> BTW, you can verify the above simplification for yourself using:
>
> (let ((ch 0) accum)
>   (while (< ch #xFFFFFFF)
>     (when (and (characterp ch)
> 	       (let ((ch2 (logand ch (lognot ?\M-\^@))))
> 		 (and (>= ch2 0) (<= ch2 127))))
>       (push ch accum))
>     (setq ch (1+ ch)))
>   (let ((standard-output (current-buffer)))
>     (princ accum)))

I had to type it myself to convince myself:

(dotimes (ch #x3FFFFF)
  (unless (equal
	   (and (characterp ch)
		(let ((ch2 (logand ch (lognot ?\M-\^@))))
		  (and (>= ch2 0) (<= ch2 127))))
	   (<= 0 ch 127))
    (error "%s" ch)))

And no `error'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 15 Oct 2021 12:28:08 +0200
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > OK, so looking even closer at this to develop test cases for the above,
> > in the original code we have this convoluted mess:
> >
> > (if (and (not need-vector)
> >          (cl-loop for ch across res
> >                   always (and (characterp ch)
> >                               (let ((ch2 (logand ch (lognot ?\M-\^@))))
> >                                 (and (>= ch2 0) (<= ch2 127))))))
> >     (concat (cl-loop for ch across res
> >                      collect (if (= (logand ch ?\M-\^@) 0)
> >                                  ch (+ ch 128))))
> >   res)
> 
> Yeah, my eyes glazed over when reading that code the first few times.
> :-) 
> 
> > But that is equivalent to:
> >
> >     (<= 0 ch 127)
> 
> I think...  you're totally right.  It looks like a very convoluted way
> to write (<= 0 ch 127).

I don't read CL-ish very well, so I cannot help you here.  (Read: I
have no idea what this code does.)

> But perhaps there's historical reasons for the code being that way?  In
> the olden days, Emacs didn't use utf-8 as the character representation,
> so perhaps it made sense back then?

The code deals with character codepoints, not with their multibyte
representation.  So UTF-8 or not doesn't seem relevant here.  It seems
to all be about character codes with modifier bits set.

Re: Moving kbd to subr.el

[Eli Zaretskii]

> Date: Fri, 15 Oct 2021 14:05:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > > (if (and (not need-vector)
> > >          (cl-loop for ch across res
> > >                   always (and (characterp ch)
> > >                               (let ((ch2 (logand ch (lognot ?\M-\^@))))
> > >                                 (and (>= ch2 0) (<= ch2 127))))))
> > >     (concat (cl-loop for ch across res
> > >                      collect (if (= (logand ch ?\M-\^@) 0)
> > >                                  ch (+ ch 128))))
> > >   res)
> > 
> > Yeah, my eyes glazed over when reading that code the first few times.
> > :-) 
> > 
> > > But that is equivalent to:
> > >
> > >     (<= 0 ch 127)
> > 
> > I think...  you're totally right.  It looks like a very convoluted way
> > to write (<= 0 ch 127).
> 
> I don't read CL-ish very well, so I cannot help you here.  (Read: I
> have no idea what this code does.)

Actually, I have to disagree with the conclusion that this is a
complicated way of saying

  (<= 0 ch 127)

That's because 'ch' can include modifier bits set, and the above code
resets them before comparing against 127.

Re: Moving kbd to subr.el

[Andreas Schwab]

On Okt 15 2021, Eli Zaretskii wrote:

> That's because 'ch' can include modifier bits set,

A modified character is no longer a characterp ...

> and the above code resets them before comparing against 127.

... thus there is nothing to reset, and (= ch ch2) always.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> That's because 'ch' can include modifier bits set,
>
> A modified character is no longer a characterp ...

Yup.

In

commit 629d4dcd2a184da6a0b246d31f152a84327db51a
Author:     Richard M. Stallman <rms@gnu.org>
AuthorDate: Tue Sep 21 03:44:04 1993 +0000

    Total rewrite by Gillespie.

+		   always (and (integerp ch)
+			       (let ((ch2 (logand ch (lognot (lsh 1 23)))))
+				 (and (>= ch2 0) (<= ch2 127))))))

which works as intended (probably), and then it became

commit ac2665815a33a8bd106741f13e06dcdd0033ea41
Author:     Dave Love <fx@gnu.org>
AuthorDate: Sun May 21 19:51:14 2000 +0000

    (edmacro-parse-keys): Return vector if any elements are invalid
    characters.

diff --git a/lisp/edmacro.el b/lisp/edmacro.el
--- a/lisp/edmacro.el
+++ b/lisp/edmacro.el
@@ -712,9 +712,9 @@
     (if (and (not need-vector)
 	     (loop for ch across res
-		   always (and (integerp ch)
+		   always (and (char-valid-p ch)
 			       (let ((ch2 (logand ch (lognot ?\M-\^@))))
 				 (and (>= ch2 0) (<= ch2 127))))))

which may or may not have worked, and then it became

commit 97443772e0967cbcfdb5e7f7a650256c7ea8b83e
Author:     Dave Love <fx@gnu.org>
AuthorDate: Wed Sep 10 17:53:50 2003 +0000


diff --git a/lisp/edmacro.el b/lisp/edmacro.el
--- a/lisp/edmacro.el
+++ b/lisp/edmacro.el
@@ -718,9 +718,9 @@
     (if (and (not need-vector)
 	     (loop for ch across res
-		   always (and (char-valid-p ch)
+		   always (and (characterp ch)

which also may or may not have worked as intended at the time.

But I think we should just replace it with the <= 127 test and not
change the behaviour any more at this point.  We could change it back to
the behaviour it probably used to have; i.e., (kbd "M-s") => "\M-s",
though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I think we should just replace it with the <= 127 test and not
> change the behaviour any more at this point.  We could change it back to
> the behaviour it probably used to have; i.e., (kbd "M-s") => "\M-s",
> though.

Which would be something like the following.  Not that I think we should.

diff --git a/lisp/edmacro.el b/lisp/edmacro.el
index a4eb574a4c..029393d86e 100644
--- a/lisp/edmacro.el
+++ b/lisp/edmacro.el
@@ -728,12 +728,16 @@ edmacro-parse-keys
       (setq res (cl-subseq res 2 -2)))
     (if (and (not need-vector)
 	     (cl-loop for ch across res
-                      always (and (characterp ch)
-                                  (let ((ch2 (logand ch (lognot ?\M-\^@))))
-                                    (and (>= ch2 0) (<= ch2 127))))))
-	(concat (cl-loop for ch across res
-                         collect (if (= (logand ch ?\M-\^@) 0)
-                                     ch (+ ch 128))))
+                      always (let ((ch2 (logand ch (lognot ?\M-\^@))))
+                               (and (>= ch2 0) (<= ch2 127)))))
+	(mapconcat (lambda (ch)
+                     (if (= (logand ch ?\M-\^@) 0)
+                         (string ch)
+                       (string-make-unibyte
+                        (string
+                         (+ (logand ch (lognot ?\M-\^@)) 128)))))
+                   res
+                   "")
       res)))
 
 (provide 'edmacro)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Monnier]

> commit 629d4dcd2a184da6a0b246d31f152a84327db51a
> Author:     Richard M. Stallman <rms@gnu.org>
> AuthorDate: Tue Sep 21 03:44:04 1993 +0000
>
>     Total rewrite by Gillespie.
>
> +		   always (and (integerp ch)
> +			       (let ((ch2 (logand ch (lognot (lsh 1 23)))))
> +				 (and (>= ch2 0) (<= ch2 127))))))
>
> which works as intended (probably), and then it became

First things first: I think `kbd` should simply always return a vector.
[ This is just repeating my stance that we should deprecate the use of
  strings as sequences of events.  ]

As for what this intends to do, I think it tries to use a string even
in the case where some of the events use the `meta` modifier, and it
does this by relying on the following bit of code in `define-key`:

    int meta_bit = (VECTORP (key) || (STRINGP (key) && STRING_MULTIBYTE (key))
                    ? meta_modifier : 0x80);

I.e. when a string is used to represent a sequence of events, that string
can include meta modifiers (represented as the 7th bit) but only if the
string is unibyte.

It's for those kinds of intricacies that I want to get rid of the use of
strings as sequences of events.


        Stefan

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> As for what this intends to do, I think it tries to use a string even
> in the case where some of the events use the `meta` modifier, and it
> does this by relying on the following bit of code in `define-key`:
>
>     int meta_bit = (VECTORP (key) || (STRINGP (key) && STRING_MULTIBYTE (key))
>                     ? meta_modifier : 0x80);
>
> I.e. when a string is used to represent a sequence of events, that string
> can include meta modifiers (represented as the 7th bit) but only if the
> string is unibyte.
>
> It's for those kinds of intricacies that I want to get rid of the use of
> strings as sequences of events.

Yeah, it's definitely an area riddled with legacy intricacies.

But at this time, I think we should retain the way `kbd' works right
now, and not try to make it output "\M-s" strings again (which it
presumably did at one time).  It most likely stopped doing that a couple
of decades ago, and nobody noticed -- which is nice, because it probably
means that we (at some point in the future) can drop the string
representation altogether (as a return value from `kbd').

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But at this time, I think we should retain the way `kbd' works right
> now, and not try to make it output "\M-s" strings again (which it
> presumably did at one time).  It most likely stopped doing that a couple
> of decades ago, and nobody noticed -- which is nice,

Yes, let sleeping dogs lie.

> because it probably
> means that we (at some point in the future) can drop the string
> representation altogether (as a return value from `kbd').

Hmm, I'd like to hear what Stefan Monnier has to say about this.

A good first step should in any case be to say in the 'kbd' docstring
that the string syntax is considered obsolete, and that callers should
prepare to handle a vector return value instead.  Perhaps we could
document this already in emacs-28.

Re: Moving kbd to subr.el

[Stefan Monnier]

>> because it probably means that we (at some point in the future) can
>> drop the string representation altogether (as a return value from
>> `kbd').
> Hmm, I'd like to hear what Stefan Monnier has to say about this.

FWIW, I removed the `need-vector` arg (and simplified the code
accordingly assuming it's always non-nil) and haven't found any
problems, so the uses that aren't prepared to handle a string return
value seem quite rare (tho Murphy swears they exist).

> A good first step should in any case be to say in the 'kbd' docstring
> that the string syntax is considered obsolete, and that callers should
> prepare to handle a vector return value instead.  Perhaps we could
> document this already in emacs-28.

Fine by me,


        Stefan

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1094 bytes --]

Stefan Kangas <stefan@marxist.se> writes:


Dogs are very honest when they are awake, which is why you should let
sleeping dogs lie.

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> But at this time, I think we should retain the way `kbd' works right
>> now, and not try to make it output "\M-s" strings again (which it
>> presumably did at one time).  It most likely stopped doing that a couple
>> of decades ago, and nobody noticed -- which is nice,
>
> Yes, let sleeping dogs lie.
>
>> because it probably
>> means that we (at some point in the future) can drop the string
>> representation altogether (as a return value from `kbd').
>
> Hmm, I'd like to hear what Stefan Monnier has to say about this.
>
> A good first step should in any case be to say in the 'kbd' docstring
> that the string syntax is considered obsolete, and that callers should
> prepare to handle a vector return value instead.  Perhaps we could
> document this already in emacs-28.
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The code deals with character codepoints, not with their multibyte
> representation.  So UTF-8 or not doesn't seem relevant here.

Sorry; I mean "Unicode code points", not utf-8.

Eli Zaretskii <eliz@gnu.org> writes:

>> > >                   always (and (characterp ch)
>> > >                               (let ((ch2 (logand ch (lognot ?\M-\^@))))
>> > >                                 (and (>= ch2 0) (<= ch2 127))))))

[...]

> Actually, I have to disagree with the conclusion that this is a
> complicated way of saying
>
>   (<= 0 ch 127)
>
> That's because 'ch' can include modifier bits set, and the above code
> resets them before comparing against 127.

But `characterp' just checks that ch is smaller than 0x3FFFFF, and

(dotimes (ch #x3FFFFF)
  (unless (equal
	   (and (characterp ch)
		(let ((ch2 (logand ch (lognot ?\M-\^@))))
		  (and (>= ch2 0) (<= ch2 127))))
	   (<= 0 ch 127))
    (error "%s" ch)))

shows no difference between the two tests in that range.  So perhaps the
logic it's trying to get at just doesn't work, or we have other problems
here.

And note:

(characterp ?\M-\^@)
=> nil

It's hard to say, but I think the code wants to allow returning "\M-s"
as a string, but it doesn't:

(edmacro-parse-keys "M-s")
=> [134217843]

So the code today is equivalent to (<= 0 ch 127), but that's probably
because it's buggy -- perhaps always has been, but perhaps it's because
we've changed how characters are represented.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Anyway -- Stefan, can you push the patch that moves kbd to subr.el to
master?  If there's any further issues with simplifying the function, we
can look into that after the change is in-tree.

(I'm doing some explorative hacking around this area, and it'd be more
convenient for me if that change is done first.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan, can you push the patch that moves kbd to subr.el to
> master?

Certainly.  Now done in commit e082a16284 and 8ee63604e3.

> If there's any further issues with simplifying the function, we
> can look into that after the change is in-tree.

We might as well fix the (<= 0 ch 127) bit, as I didn't do that in my patch.

(I know there are different styles, but I personally often think it's
nice to put such cleanups in their own commits to facilitate later
bisecting.)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Certainly.  Now done in commit e082a16284 and 8ee63604e3.

Thanks!

> We might as well fix the (<= 0 ch 127) bit, as I didn't do that in my patch.
>
> (I know there are different styles, but I personally often think it's
> nice to put such cleanups in their own commits to facilitate later
> bisecting.)

Sure.  I waffle between the two styles because I don't want to add noise
(so fewer commits are better), but at the same time, keeping cleanups
separate makes the functional changes easier to comprehend (so more
commits are better).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

I went with the

["C-c C-c"]

syntax, and changes are now pushed to the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Gregory Heytings]

>
> I went with the
>
> ["C-c C-c"]
>
> syntax, and changes are now pushed to the trunk.
>

I still believe that using strings would have been better, but okay, "the 
ship has sailed".

A suggestion:

(kbd-valid-p "<mouse-1>")
(kbd-valid-p "<Scroll_Lock>")

should return t, and

(kbd-valid-p "<123>")

should (I think) return nil.  IOW, kbd-valid-p should use:

(string-match-p "\\`<[A-Za-z][A-Za-z0-9_-]*>\\'" key)

Re: Moving kbd to subr.el

[Eli Zaretskii]

> Date: Sun, 17 Oct 2021 19:32:26 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org
> 
> (kbd-valid-p "<123>")
> 
> should (I think) return nil.

Why? can't there be a function key named "123"?

Re: Moving kbd to subr.el

[Gregory Heytings]

>> (kbd-valid-p "<123>")
>>
>> should (I think) return nil.
>
> Why? can't there be a function key named "123"?
>

You mean, "<f123>"?

(kbd "<123>") returns [\123]

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> You mean, "<f123>"?
>
> (kbd "<123>") returns [\123]

I was momentarily confused, but that's the symbol with a name "123",
which means that kbd thinks that's a fine symbolic key name.  (This may
be an error, though.)

(equal [\123] [123])
=> nil

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 17 Oct 2021 21:58:36 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > You mean, "<f123>"?
> >
> > (kbd "<123>") returns [\123]
> 
> I was momentarily confused, but that's the symbol with a name "123",
> which means that kbd thinks that's a fine symbolic key name.  (This may
> be an error, though.)
> 
> (equal [\123] [123])
> => nil

Why does kbd generate the leading backslash, though?

Re: Moving kbd to subr.el

[Gregory Heytings]

>
> Why does kbd generate the leading backslash, though?
>

Because it's the way Emacs uses to disambiguate symbols that could be 
understood as something else:

(defun \0 () (interactive) (message "zero"))
M-x 0 RET

Re: Moving kbd to subr.el

[Eli Zaretskii]

> Date: Mon, 18 Oct 2021 11:52:15 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, stefankangas@gmail.com, 
>     emacs-devel@gnu.org
> 
> > Why does kbd generate the leading backslash, though?
> >
> 
> Because it's the way Emacs uses to disambiguate symbols that could be 
> understood as something else:
> 
> (defun \0 () (interactive) (message "zero"))
> M-x 0 RET

In the context of key sequences, it will be mighty confusing, I think.

Re: Moving kbd to subr.el

[Gregory Heytings]

>>> Why does kbd generate the leading backslash, though?
>>
>> Because it's the way Emacs uses to disambiguate symbols that could be 
>> understood as something else:
>>
>> (defun \0 () (interactive) (message "zero"))
>> M-x 0 RET
>
> In the context of key sequences, it will be mighty confusing, I think.
>

Yes, but as discussed "123" is not a valid event symbol name anyway.  I 
think it's more a side effect of the general disambiguation mechanism used 
by Emacs than something that kbd does on purpose.

Re: Moving kbd to subr.el

[Stefan Monnier]

>> > You mean, "<f123>"?
>> >
>> > (kbd "<123>") returns [\123]
>> 
>> I was momentarily confused, but that's the symbol with a name "123",
>> which means that kbd thinks that's a fine symbolic key name.  (This may
>> be an error, though.)
>> 
>> (equal [\123] [123])
>> => nil
>
> Why does kbd generate the leading backslash, though?

`kbd` doesn't.  It's the printer which adds the backslash in front of
symbols whose first char is a number.


        Stefan

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > > You mean, "<f123>"?
  > > >
  > > > (kbd "<123>") returns [\123]
  > > 
  > > I was momentarily confused, but that's the symbol with a name "123",
  > > which means that kbd thinks that's a fine symbolic key name.  (This may
  > > be an error, though.)
  > > 
  > > (equal [\123] [123])
  > > => nil

We DON'T HAVE TO stick to the syntax we have used with kbd.

If we are going to relegate the old syntax to "permanently deprecated"
as I recommend, we can design a new syntax, whichever syntax we like.
It doesn't have to use the function `kbd'.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> If we are going to relegate the old syntax to "permanently deprecated"
> as I recommend, we can design a new syntax, whichever syntax we like.
> It doesn't have to use the function `kbd'.

The syntax that `kbd' understands is the one that we're using to display
keystrokes in help texts and manuals, so inventing another syntax for
defining keys doesn't seem productive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The syntax that `kbd' understands is the one that we're using to display
> keystrokes in help texts and manuals, so inventing another syntax for
> defining keys doesn't seem productive.

One idea is to disallow string syntax on the 'kbd-*' level of the API,
and have another function intended for end-users in their init file that
does allow string syntax.

I can't remember if it has been mentioned before, but John Wiegley's
bind-key.el (part of use-package) is one alternative for this.  Its
documentation is here:

    https://github.com/jwiegley/use-package/blob/master/bind-key.el

One nice thing about `bind-keys' is that you differentiate between your
own keybindings and those from Emacs and packages; you show all personal
key bindings with `M-x describe-personal-keybindings'.  This lists only
those keybindings added with `bind-key'.

(I believe that we already have the copyright assignment for
bind-keys.el specifically, even if we don't have it for the full
use-package.el.  The only remaining contributor to sort assignments for
use-package.el has only 6 lines added to the file bind-keys.el.)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> One idea is to disallow string syntax on the 'kbd-*' level of the API,
> and have another function intended for end-users in their init file that
> does allow string syntax.

By "string syntax", do you mean the kdb string syntax or the old one?
:-) 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> One idea is to disallow string syntax on the 'kbd-*' level of the API,
>> and have another function intended for end-users in their init file that
>> does allow string syntax.
>
> By "string syntax", do you mean the kdb string syntax or the old one?
> :-)

The kbd syntax, a.k.a. the one in our documentation.

(Perhaps a DWIM-version rather than the newly introduced strict one?)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> (Perhaps a DWIM-version rather than the newly introduced strict one?)

Strict versions are nice because then you get errors when you do
something wrong instead of it subtly not working.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Strict versions are nice because then you get errors when you do
> something wrong instead of it subtly not working.

That's true.  I'm just not sure how that balances out.

If we are keeping support for a string syntax in the 'kbd-*' functions,
it's probably a good idea to make it strict.  And then it seems prudent
to just use that same syntax everywhere.

But let's say we were to promote `kbd-*' mainly for use in Emacs and
packages, and that we drop support for string syntax there (only
allowing instead e.g. the XEmacs [(control meta x)] syntax).  And let's
say we coupled this with promoting e.g. `bind-key' as the strictly
user-facing way to bind keys.  In this case, perhaps the balance would
be different.

For example, do we need to demand "C-<return>" instead of "C-return" in
our strictly user-facing function?  Maybe not.  But we should IMO
definitely demand that if you want to bind a command to the six
character sequence, you need to specify that as "r e t u r n".

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> But let's say we were to promote `kbd-*' mainly for use in Emacs and
> packages, and that we drop support for string syntax there (only
> allowing instead e.g. the XEmacs [(control meta x)] syntax).  And let's
> say we coupled this with promoting e.g. `bind-key' as the strictly
> user-facing way to bind keys.  In this case, perhaps the balance would
> be different.
>
> For example, do we need to demand "C-<return>" instead of "C-return" in
> our strictly user-facing function?  Maybe not.  But we should IMO
> definitely demand that if you want to bind a command to the six
> character sequence, you need to specify that as "r e t u r n".

I don't see much value in allowing either the XEmacs syntax nor a sloppy
kbd syntax here.  I do see value in having the syntax be exactly the
same as `describe-key' outputs -- then the user knows that they can
round-trip these things from `kbd-bind' to seeing it in *Help* in
exactly the same form.

You (kbd-local-bind "C-<return>") and then you hit `C-h b' and see
C-<return> in the *Help* buffer and all is well with the world, and
there's nothing mysterious going on.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> do we need to demand "C-<return>" instead of 
> "C-return" in our strictly user-facing function?
> Maybe not.

Not.  Whether "strictly user-facing" or not
(whatever you might mean by that phrase).

See what I wrote (and implemented in naked.el).
Angle brackets can easily be made optional.

They could be dropped altogether (they weren't
used before Emacs 21), but it's trivial to keep
them as optional.

> But we should IMO definitely demand that if
> you want to bind a command to the six
> character sequence, you need to specify that
> as "r e t u r n".

`kbd' says (today) you need to use SPC, not " ".
I don't see that as a bad thing, for key-sequence
descriptions.  That's the way Emacs (*Help*)
talks to you about such key sequences.  SPC is
no different from RET or DEL or TAB or ...

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 913 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:


Lars -- I agree in principle, but I think the details matter; let's
rephrase as "We dont need to or even *shouldn't* plan to support *every*
syntactic nuance used by kbd".

Many of the weird corner cases that kbd supports --- likely mostly by
accident --- will never be typed by users in their emacs configuration.


> Richard Stallman <rms@gnu.org> writes:
>
>> If we are going to relegate the old syntax to "permanently deprecated"
>> as I recommend, we can design a new syntax, whichever syntax we like.
>> It doesn't have to use the function `kbd'.
>
> The syntax that `kbd' understands is the one that we're using to display
> keystrokes in help texts and manuals, so inventing another syntax for
> defining keys doesn't seem productive.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> Lars -- I agree in principle, but I think the details matter; let's
> rephrase as "We dont need to or even *shouldn't* plan to support *every*
> syntactic nuance used by kbd".
>
> Many of the weird corner cases that kbd supports --- likely mostly by
> accident --- will never be typed by users in their emacs configuration.

Oh, no -- we're aiming for the syntax defined by `kdb-valid-p', which is
a small subset of the stuff that `kbd' accepts.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[T.V Raman]

SG!

Let's codify this decision  by adding comments to the code that say
that in case of disagreement between kbd and kbd-valid-p, kbd  is
authoritative --- thi salso meets my earlier request for having  a
firm spec what valid keys are.
Lars Ingebrigtsen writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > Lars -- I agree in principle, but I think the details matter; let's
 > > rephrase as "We dont need to or even *shouldn't* plan to support *every*
 > > syntactic nuance used by kbd".
 > >
 > > Many of the weird corner cases that kbd supports --- likely mostly by
 > > accident --- will never be typed by users in their emacs configuration.
 > 
 > Oh, no -- we're aiming for the syntax defined by `kdb-valid-p', which is
 > a small subset of the stuff that `kbd' accepts.
 > 
 > -- 
 > (domestic pets only, the antidote for overdose, milk.)
 >    bloggy blog: http://lars.ingebrigtsen.no

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Moving kbd to subr.el

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> If we are going to relegate the old syntax to "permanently deprecated"
>> as I recommend, we can design a new syntax, whichever syntax we like.
>> It doesn't have to use the function `kbd'.
>
> The syntax that `kbd' understands is the one that we're using to display
> keystrokes in help texts and manuals, so inventing another syntax for
> defining keys doesn't seem productive.

That doesn't mean that the new functions couldn't be more lax while
parsing, and dwim when I say C-f1 for M-space.

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> That doesn't mean that the new functions couldn't be more lax while
> parsing, and dwim when I say C-f1 for M-space.

That sounds very lax indeed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> That doesn't mean that the new functions couldn't be more lax while
>> parsing, and dwim when I say C-f1 for M-space.
>
> That sounds very lax indeed.

Do you think it would be impractical?

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

>>> That doesn't mean that the new functions couldn't be more lax while
>>> parsing, and dwim when I say C-f1 for M-space.
>>
>> That sounds very lax indeed.
>
> Do you think it would be impractical?

Depends.  Do you also mean M-<return> when you say C-<home>?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> That doesn't mean that the new functions couldn't be more lax while
>>>> parsing, and dwim when I say C-f1 for M-space.
>>>
>>> That sounds very lax indeed.
>>
>> Do you think it would be impractical?
>
> Depends.  Do you also mean M-<return> when you say C-<home>?

No, but I am not sure what you mean by this.

My point is that instead of extending or creating a new syntax, that the
new functions could handle a superset of what kbd currently does. So
where as (kbd "C-f1") currently throws an error, the new functions could
interpret the previous expression to be equivalent to (kbd "C-<f1>").

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

>>>>> That doesn't mean that the new functions couldn't be more lax while
>>>>> parsing, and dwim when I say C-f1 for M-space.
>>>>
>>>> That sounds very lax indeed.
>>>
>>> Do you think it would be impractical?
>>
>> Depends.  Do you also mean M-<return> when you say C-<home>?
>
> No, but I am not sure what you mean by this.
>
> My point is that instead of extending or creating a new syntax, that the
> new functions could handle a superset of what kbd currently does. So
> where as (kbd "C-f1") currently throws an error, the new functions could
> interpret the previous expression to be equivalent to (kbd "C-<f1>").

But you said that C-f1 should be interpreted as M-space, so I wasn't
sure what you were getting at.

But, no, I don't think the functions should be lax when interpreting
these strings -- it's just confusing.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>>>> That doesn't mean that the new functions couldn't be more lax while
>>>>>> parsing, and dwim when I say C-f1 for M-space.
>>>>>
>>>>> That sounds very lax indeed.
>>>>
>>>> Do you think it would be impractical?
>>>
>>> Depends.  Do you also mean M-<return> when you say C-<home>?
>>
>> No, but I am not sure what you mean by this.
>>
>> My point is that instead of extending or creating a new syntax, that the
>> new functions could handle a superset of what kbd currently does. So
>> where as (kbd "C-f1") currently throws an error, the new functions could
>> interpret the previous expression to be equivalent to (kbd "C-<f1>").
>
> But you said that C-f1 should be interpreted as M-space, so I wasn't
> sure what you were getting at.

Oh my, now I understand what you mean. No, that was a typo ("or" ->
"for"). Sorry about that.

> But, no, I don't think the functions should be lax when interpreting
> these strings -- it's just confusing.  

How come? It could just as well be argued that throwing errors while
parsing key bindings is also confusing, especially when guessing that
C-f1 is the same C-<f1> isn't that far of a jump.

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> How come? It could just as well be argued that throwing errors while
> parsing key bindings is also confusing, especially when guessing that
> C-f1 is the same C-<f1> isn't that far of a jump.

Because then you end up with code that says

(define-keymap
...
"C-f1" 'some-function
"C-<f2>" 'other-function)

and the person reading it will then wonder "but what's the difference"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How come? It could just as well be argued that throwing errors while
>> parsing key bindings is also confusing, especially when guessing that
>> C-f1 is the same C-<f1> isn't that far of a jump.
>
> Because then you end up with code that says
>
> (define-keymap
> ...
> "C-f1" 'some-function
> "C-<f2>" 'other-function)
>
> and the person reading it will then wonder "but what's the difference"?

But doesn't this issue already exist? e.g. kbd parses both "C-c" and
"^C", which might lead to the same confusion ("is one of these for X11
and the other one for TUI Emacs?", they might ask).

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> But doesn't this issue already exist? e.g. kbd parses both "C-c" and
> "^C", which might lead to the same confusion ("is one of these for X11
> and the other one for TUI Emacs?", they might ask).

Exactly!  That's why these new commands do not accept the "^C" syntax,
either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We can move `kbd' to subr.el as is, for short-term convenience, and we
can leave it there permanently if that's useful.  But that doesn't
mean we have to adopt `kbd' syntax as our permanent new key binding
syntax.

Let's not rush to decide that new syntax!

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, eliz@gnu.org, emacs-devel@gnu.org,
> 	gregory@heytings.org, stefankangas@gmail.com
> Date: Sat, 23 Oct 2021 19:29:25 -0400
> 
> We can move `kbd' to subr.el as is, for short-term convenience

It's already there, has been for the last 9 years.

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > We can move `kbd' to subr.el as is, for short-term convenience

  > It's already there, has been for the last 9 years.

Sorry, I assumed from the complaints about calling kbd too early on
that the problem was that it wasn't defined yet.

But that's a side issue.  The point is, let's not prematurely assume that
the key binding syntax we settle on has to be that of kbd.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> We can move `kbd' to subr.el as is, for short-term convenience, and we
> can leave it there permanently if that's useful.  But that doesn't
> mean we have to adopt `kbd' syntax as our permanent new key binding
> syntax.
>
> Let's not rush to decide that new syntax!

We're not rushing -- `describe-key' has been around for quite a while,
and that's the syntax we're using.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Hi Emacs devs!

On Sun, Oct 24, 2021, 08:24 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
> > We can move `kbd' to subr.el as is, for short-term convenience, and we
> > can leave it there permanently if that's useful.  But that doesn't
> > mean we have to adopt `kbd' syntax as our permanent new key binding
> > syntax.
> >
> > Let's not rush to decide that new syntax!
>
> We're not rushing -- `describe-key' has been around for quite a while,
> and that's the syntax we're using.
>

Apropos rushing..

AFAIK bind-keys (from use-package) is fairly stable.  Discussion of it in
this thread fell by the wayside, I think.  Is there a reason for that I may
have missed?  (I'm traveling these last few days and may well be poorly
following the lists from my mobile.)

Are there design goals at stake here that bind-keys leaves aside?  And,
assuming there, would someone be so kind as to enumerate the design goals
for a new keyboard binding layer?

Can compatibility with bind-keys be considered as (at least) nice to have
in such a list?

My sense is that quite a number of people use it (via use-package).  In
fact, I would tend to assume use-package's bind-key is the most
popular/well-used not-yet-supported-in-core means of setting up complex
user defined key-bindings.

If these (data-free) assertions are true, supporting (whether or not
actually using) bind-key may be preferable to 'socializing' the rationale
for different heuristics.

[-- Attachment #2: Type: text/html, Size: 2211 bytes --]

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Corwin Brust <corwin@bru.st> writes:

> Are there design goals at stake here that bind-keys leaves aside?  And,
> assuming there, would someone be so kind as to enumerate the design goals
> for a new keyboard binding layer?

I'm not quite sure what you're asking -- that Emacs should be pre-loaded
with bind-keys?

As far as I know, bind-keys uses the same syntax that we're moving to.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Thank you for the reply, Lars.

On Sun, Oct 24, 2021, 13:42 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Corwin Brust <corwin@bru.st> writes:
>
> > Are there design goals at stake here that bind-keys leaves aside?  And,
> > assuming there, would someone be so kind as to enumerate the design goals
> > for a new keyboard binding layer?
>
> I'm not quite sure what you're asking


Now that you ask, I wonderifmy thinkingis muddled, here.

-- that Emacs should be pre-loaded
> with bind-keys?
>

That sounds great to me   Are there barriers or concerns?


> As far as I know, bind-keys uses the same syntax that we're moving to.
>

Mainly, I'm interested in the goal of the present work.  Perfect, to help
me understand, would be to put that as a list of 'bullet point' objectives.

I will have access to a personal computer tonight.  I'll review this thread
thoroughly.  Likely I can then see the answers from that already once I do.

Sorry if I've created undue noise -- and tia for any 'goals in summay'
anyone troubles to make.

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: Moving kbd to subr.el

[Philip Kaludercic]

Corwin Brust <corwin@bru.st> writes:

> Thank you for the reply, Lars.
>
> On Sun, Oct 24, 2021, 13:42 Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> Corwin Brust <corwin@bru.st> writes:
>>
>> > Are there design goals at stake here that bind-keys leaves aside?  And,
>> > assuming there, would someone be so kind as to enumerate the design goals
>> > for a new keyboard binding layer?
>>
>> I'm not quite sure what you're asking
>
>
> Now that you ask, I wonderifmy thinkingis muddled, here.
>
> -- that Emacs should be pre-loaded
>> with bind-keys?
>>
>
> That sounds great to me   Are there barriers or concerns?

If I am not mistaken, bind-keys is a package for user-configurations,
right? The intention is to provide a better syntax for modifying
existing key maps, while this discussion is about extending core Emacs
to simplify the definitions of key maps in (among other things)
preloaded packages.

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If I am not mistaken, bind-keys is a package for user-configurations,
  > right? The intention is to provide a better syntax for modifying
  > existing key maps, while this discussion is about extending core Emacs
  > to simplify the definitions of key maps in (among other things)
  > preloaded packages.

Despite those differences in context, it may be possible to use one
and the same syntax to specify each key to be bound, in both
situations.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We're not rushing -- `describe-key' has been around for quite a while,
  > and that's the syntax we're using.

I don't follow -- which syntax is that?
When I run `dsscribe-key', it wants actual keys as input,
not syntactic descriptions of them.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > We're not rushing -- `describe-key' has been around for quite a while,
>   > and that's the syntax we're using.
>
> I don't follow -- which syntax is that?
> When I run `dsscribe-key', it wants actual keys as input,
> not syntactic descriptions of them.

The syntax `describe-key' outputs.

(describe-key "\M-e")
->
It is bound to M-e.

It's a subset of the syntax `kbd' accepts, and is what I'm targeting.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's a subset of the syntax `kbd' accepts, and is what I'm targeting.

Would you please post the precise description of the proposed input
syntax?  I don't think we ever used it as an input syntax before,
so we would not have written a precise description.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > It's a subset of the syntax `kbd' accepts, and is what I'm targeting.
>
> Would you please post the precise description of the proposed input
> syntax?  I don't think we ever used it as an input syntax before,
> so we would not have written a precise description.

From the doc string:

Here’s some example key sequences:

    "f"
    "C-c C-c"
    "H-<left>"
    "M-RET"
    "C-M-<return>"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Here’s some example key sequences:

  >     "f"
  >     "C-c C-c"
  >     "H-<left>"
  >     "M-RET"
  >     "C-M-<return>"

Those examples look reasonable -- but we really need a precise
description of the rules for valid input.  We need that now
so we can study it together before adopting it.
 
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Those examples look reasonable -- but we really need a precise
> description of the rules for valid input.  We need that now
> so we can study it together before adopting it.

Have a look at the kbd-valid-p doc string on the current trunk for a
definition.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Have a look at the kbd-valid-p doc string on the current trunk for a
  > definition.

I've included that text below, because now is the time
for people to look at and comment on it.

Should the syntax Emacs adopts for the next 20 years be this one?
This one with some changes?
Any other proposal?

If we use this syntax, the text we use to define it in the Emacs Lisp
Ref Manual should cover valid cases not mentioned in this text.
We don't use them in normal Emacs bindings, but they are valid
so they should be documented.

======================================================================
Say whether KEYS is a valid `kbd' sequence.
A `kbd' sequence is a string consisting of one and more key
strokes.  The key strokes are separated by a space character.

Each key stroke is either a single character, or the name of an
event, surrounded by angle brackets.  In addition, any key stroke
may be preceded by one or more modifier keys.  Finally, a limited
number of characters have a special shorthand syntax.

Here's some example key sequences.

  \"f\"           (the key 'f')
  \"S o m\"       (a three key sequence of the keys 'S', 'o' and 'm')
  \"C-c o\"       (a two key sequence of the keys 'c' with the control modifier
                 and then the key 'o')
  \"H-<left>\"    (the key named \"left\" with the hyper modifier)
  \"M-RET\"       (the \"return\" key with a meta modifier)
  \"C-M-<space>\" (the \"space\" key with both the control and meta modifiers)

These are the characters that have shorthand syntax:
NUL, RET, TAB, LFD, ESC, SPC, DEL.

Modifiers have to be specified in this order:

   A-C-H-M-S-s

which is

   Alt-Control-Hyper-Meta-Shift-super


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[John Yates]

> A `kbd' sequence is a string consisting of one and more key
> strokes.  The key strokes are separated by a space character.

Is "a space character" normative?  I am an avid fan of aligning
text to achieve tabular presentation.  Per the above definition
I am allowed only a single space.  Could this not be relaxed
to "separated by whitespace"?

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > A `kbd' sequence is a string consisting of one and more key
  > > strokes.  The key strokes are separated by a space character.

  > Is "a space character" normative?

I'm surprised by this terminology -- could you explain what that
question means, using different words?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Robert Pluim]

>>>>> On Wed, 03 Nov 2021 22:36:10 -0400, Richard Stallman <rms@gnu.org> said:

    rms> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    rms> [[[ whether defending the US Constitution against all enemies,     ]]]
    rms> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> > A `kbd' sequence is a string consisting of one and more key
    >> > strokes.  The key strokes are separated by a space character.

    >> Is "a space character" normative?

    rms> I'm surprised by this terminology -- could you explain what that
    rms> question means, using different words?

"normative" in the sense of "imposing a norm or standard". Itʼs a
common expression in standards documents, to separate things that must
be obeyed from things that are mere comments.

In this case, John is asking: "Does this mean that there must be one
and only one space character separating the key strokes?"

Robert
-- 

Re: New key binding syntax

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> In this case, John is asking: "Does this mean that there must be one
> and only one space character separating the key strokes?"

If that's what he's asking, the answer is "yes".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New key binding syntax

[John Yates]

On Thu, Nov 4, 2021 at 1:10 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Robert Pluim <rpluim@gmail.com> writes:
> > In this case, John is asking: "Does this mean that there must be one
> > and only one space character separating the key strokes?"
> If that's what he's asking, the answer is "yes".

Lars,

Are you describing the behavior of the existing code
or are you articulating a design stance.  If the latter,
would you please explain?  (I shared my motivation
for desiring a more permissive syntax in my original
email.)

/john

Re: New key binding syntax

[Lars Ingebrigtsen]

John Yates <john@yates-sheets.org> writes:

> Are you describing the behavior of the existing code
> or are you articulating a design stance.  If the latter,
> would you please explain?  (I shared my motivation
> for desiring a more permissive syntax in my original
> email.)

Did you want more or fewer spaces between characters than one?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New key binding syntax

[John Yates]

On Thu, Nov 4, 2021 at 6:48 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Did you want more or fewer spaces between characters than one?

One or more, so that I can arrange consecutive bindings into columns.
I do not seek zero spaces.  That would be a step backwards in legibility.
So I, at least, would never use it.

/john

Re: New key binding syntax

[Lars Ingebrigtsen]

John Yates <john@yates-sheets.org> writes:

> One or more, so that I can arrange consecutive bindings into columns.
> I do not seek zero spaces.  That would be a step backwards in legibility.

There is value in having the same string being presented by `C-h b' as
the one you use in your .emacs -- there's no confusion about whether
there's any difference between "C-c C-M-a" and "C-c   M-C-a", and when
Emacs says that the key is "C-c C-M-a", you know that you can grep the
sources for exactly the string "C-c C-M-a" and find the binding.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New key binding syntax

[John Yates]

On Thu, Nov 4, 2021 at 10:25 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> There is value in having the same string being presented by `C-h b' as
> the one you use in your .emacs -- there's no confusion about whether
> there's any difference between "C-c C-M-a" and "C-c   M-C-a", and when
> Emacs says that the key is "C-c C-M-a", you know that you can grep the
> sources for exactly the string "C-c C-M-a" and find the binding.

Can you point to other situations, familiar to Emacs users, where a similar
formulation of whitespace occurs?  Contrast that with the nearly countless
context in which whitespace is a lexical pattern.

And in Emacs especially, when would I grep for the source of a binding
after having it displayed by Emacs.  My immediate response would be
"C-h k".

Finally, I will point out that you are retracting current keydef functionality.

/john

Re: New key binding syntax

[Lars Ingebrigtsen]

John Yates <john@yates-sheets.org> writes:

> Can you point to other situations, familiar to Emacs users, where a similar
> formulation of whitespace occurs?  Contrast that with the nearly countless
> context in which whitespace is a lexical pattern.

All characters usually count when dealing with strings.

> And in Emacs especially, when would I grep for the source of a binding
> after having it displayed by Emacs.  My immediate response would be
> "C-h k".

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

> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: New key binding syntax

[John Yates]

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.

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > In this case, John is asking: "Does this mean that there must be one
  > > and only one space character separating the key strokes?"

  > If that's what he's asking, the answer is "yes".

Is it good to require one-space-and-only-one?  We could change that
code, or we could keep it the same.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Alexandre Garreau]

Le vendredi 5 novembre 2021, 04:57:32 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > In this case, John is asking: "Does this mean that there must be
>   > > one
>   > > and only one space character separating the key strokes?"
>   > 
>   > If that's what he's asking, the answer is "yes".
> 
> Is it good to require one-space-and-only-one?  We could change that
> code, or we could keep it the same.

currently, even worse, it supports 0-spaces, and it works just the same 
(you have to put a dash, so no dash has counter-intuitively more 
precedence than the dash), so my proposition of stating “C-M-ab” for a 
chord doesn’t even hold without introducing a backward-incompatibility.

Please note also that any unknown modifier will cause the dash to have the 
meaning of a dash (that is writing (kbd "c-c") will mean “hit c, then hit 
-, then hit c again), which is counter intuitive to me (because depending 
of the context (not even the syntax, but the lexic) the dash has a 
different meaning, I would expected that to be written “c - c”, or else to 
trigger some error.  There’s some forward-compat’ design though that could 
be useful there.

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In this case, John is asking: "Does this mean that there must be one
  > and only one space character separating the key strokes?"

What format to allow for specifying a key sequence to bind is up to us.
All these decisions can be decided now.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Dmitry Gutov]

On 02.11.2021 06:54, Richard Stallman wrote:
> Modifiers have to be specified in this order:
> 
>     A-C-H-M-S-s

I guess the order-of-modifiers checking gives me a little pause.

Seems like it'll bring its own challenge of validating input and telling 
the users about problems in said order.

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Modifiers have to be specified in this order:
  > > 
  > >     A-C-H-M-S-s

  > I guess the order-of-modifiers checking gives me a little pause.

I don't see any reason to insist on having the modifiers in this order.
Why not allow any order?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Alexandre Garreau]

Le mardi 2 novembre 2021, 04:54:17 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Have a look at the kbd-valid-p doc string on the current trunk for a
>   > definition.
> 
> I've included that text below, because now is the time
> for people to look at and comment on it.
> 
> Should the syntax Emacs adopts for the next 20 years be this one?
> This one with some changes?

What wasn’t that ever normalized/documented? it always seemed to be that 
“kbd” was the standard way of specifying keystrokes… was it just informal?

> Any other proposal?

I always wondered: if one day emacs was to allow to gracefully support 
key-chords [0] (that is, using any key other as a “modifier”, so that you 
could press a and b at the same time and it would be a special keystrokes, 
which makes expressivity of keystrokes increase factorially with length 
instead of exponentially), at least in certain configurations.

That feature (actually, dirty hack, for now, but the author consider emacs 
to be misdesigned apparently, according implementation notes) is even 
advertised on emacs’ webpage through the emacsrock serie [1]

The extension currently looks dirty, and isn’t integrated into kbd at all, 
but if it were to be, should Control+Meta+a+b (a and b being the lowercase 
letters a and b, not variables) be specified “C-M-ab” or “C-M-a-b”: the 
most intuitive would be the later, because - aquires some kind of semantic 
of “at the same time” (which most of other programs describe with a “+” 
nowadays, which is less confusing, so C-M-a-b would be Control+Meta+A+B 
(they also usually are case-insensitive, while emacs case-sensitive 
afaiu)), but if a keyboard layout included a “uppercase A” key, and one 
used uppercase letters in keystrokes, then it would be impossible to say 
C-A-B” without A being understood as Alt (and using a rigid order for 
specifying modifiers in order to distinguish them from else looks 
confusing).  C-M-ab is somewhat less logical but wouldn’t break the 
existing interpretation.  Could a definition allowing a such form (although 
saying it is by default unsupported) be considered?

Furthermore, I would be in favor (and maybe that could help people to 
switch more seemlessly to emacs) to relax that syntax (as long as it is 
not ambiguous) and tweak it per-configuration (so when a keystroke is 
displayed, such as in minibuffer, in *Help* etc. it could be displayed 
differently), such as to for instance allow using a + character instead of 
a - (which is now more widespread and easily understood, although I find 
the - more sober hence more beautiful, but that’s maybe personal 
conservatism linked to habitude, and then it would be nice to only keep 
that as a personal configuration), or sometimes specifying the modifiers 
names all written (such as “Meta-” instead of “M-”: currently that causes 
no ambiguity as “Meta-” is translated as such and has no meaning afaik) if 
the user wishes to, so that for instance config/UI looks more 
understandable to outsiders and newcomers (I have to note that *merely 
looking* at a used (habituated? how to say?) user of emacs is per se an 
important form of advertisement of emacs (it makes people curious, it 
looks fast, it looks confident, it works great))

> If we use this syntax, the text we use to define it in the Emacs Lisp
> Ref Manual should cover valid cases not mentioned in this text.
> We don't use them in normal Emacs bindings, but they are valid
> so they should be documented.

could it be possible for keystrokes as displayed by a manual to be 
configurable? such as having (maybe that’s already the case) semantical 
markup for those, so that at compilation, or at visualisation (if the 
software supports it) they can be displayed differently, such as as I 
proposed.

> ======================================================================
> Say whether KEYS is a valid `kbd' sequence.
> A `kbd' sequence is a string consisting of one and more key
> strokes.  The key strokes are separated by a space character.

I agree with what was said that this should be a partitive “whitespace”, 
not an absolute space character.  That could be translated to a canonical 
form with only one space character later (after all differences in 
whitespace are irrelevant out of context).

> Each key stroke is either a single character, or the name of an
> event, surrounded by angle brackets.  In addition, any key stroke
> may be preceded by one or more modifier keys.  Finally, a limited
> number of characters have a special shorthand syntax.

> Here's some example key sequences.
> 
>   \"f\"           (the key 'f')
>   \"S o m\"       (a three key sequence of the keys 'S', 'o' and 'm')
>   \"C-c o\"       (a two key sequence of the keys 'c' with the control
> modifier and then the key 'o')
>   \"H-<left>\"    (the key named \"left\" with the hyper modifier)
>   \"M-RET\"       (the \"return\" key with a meta modifier)
>   \"C-M-<space>\" (the \"space\" key with both the control and meta
> modifiers)



> Modifiers have to be specified in this order:
> 
>    A-C-H-M-S-s
> 
> which is
> 
>    Alt-Control-Hyper-Meta-Shift-super

What happens otherwise? an error? or, more gracefully, a translation? that 
could be a canonical order (that’s just alphabetical right?)

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What wasn’t that ever normalized/documented? it always seemed to be that 
  > “kbd” was the standard way of specifying keystrokes… was it just informal?

It was a convenient way of specifying key sequences -- never more than that.

  > I always wondered: if one day emacs was to allow to gracefully support 
  > key-chords [0] (that is, using any key other as a “modifier”, so that you 
  > could press a and b at the same time and it would be a special keystrokes, 
  > which makes expressivity of keystrokes increase factorially with length 
  > instead of exponentially), at least in certain configurations.

That sounds nice, but using non-modifier keys as modifiers has an
inherent problem: those keys are supposed to do rollover.
If you press a, and while holding it down, press b, that is supposed
to mean a followed by b.

To make that count as "b modified by a", we would need to change how
the keyboard handles the a key.


  > That feature (actually, dirty hack, for now, but the author consider emacs 
  > to be misdesigned apparently, according implementation notes) is even 
  > advertised on emacs’ webpage through the emacsrock serie [1]

Sorry, I can't make sense of that.  What is "emacsrock"?  What does
"[1]" refer to?  When you say "on Emacs' webpage", what exact URL do
you mean?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Yuri Khan]

On Thu, 4 Nov 2021 at 09:34, Richard Stallman <rms@gnu.org> wrote:

> That sounds nice, but using non-modifier keys as modifiers has an
> inherent problem: those keys are supposed to do rollover.
> If you press a, and while holding it down, press b, that is supposed
> to mean a followed by b.
>
> To make that count as "b modified by a", we would need to change how
> the keyboard handles the a key.

These days, the keyboard does not handle this kind of rollover. All it
does is report the up/down state of all 8 standard modifier keys (left
and right GUI, Alt, Ctrl, Shift) and up to 6 normal keys that are
down. (There are ways for a keyboard to be able to report more than 6;
such boards are advertised as NKRO (N-Key Rollover) and it’s a gamer
feature.)

The rollover behavior works entirely on the application side, where
the OS and the GUI toolkit send events like “the key at position AB02
was pressed while the left Alt is down; by the way, the character for
this key in the current layout is x”. If the application reacts to key
press and autorepeat events and takes the character and modifiers from
them immediately, the “AC01 down (char a), AB05 down (char b), AC01 up
(char a), AB05 up (char b)” sequence results in an “a then b” text
input. But some applications (notably games) just track the whole bit
array of keys.

Modern terminal emulators such as Kitty also make this kind of events
available, although, for backward compatibility reasons, the
application has to detect that this protocol extension is supported
and opt-in to using it.

To recap: If Emacs decided to support chord input, it would not
require any hardware modifications or OS tweaks, it would be a feature
entirely in Emacs. It would not be available in some terminal
emulators, that’s all.

Re: New key binding syntax

[Alexandre Garreau]

Le jeudi 4 novembre 2021, 09:53:23 CET Yuri Khan a écrit :
> On Thu, 4 Nov 2021 at 09:34, Richard Stallman <rms@gnu.org> wrote:
> > That sounds nice, but using non-modifier keys as modifiers has an
> > inherent problem: those keys are supposed to do rollover.
> > If you press a, and while holding it down, press b, that is supposed
> > to mean a followed by b.
> > 
> > To make that count as "b modified by a", we would need to change how
> > the keyboard handles the a key.
> 
> These days, the keyboard does not handle this kind of rollover. All it
> does is report the up/down state of all 8 standard modifier keys (left
> and right GUI, Alt, Ctrl, Shift) and up to 6 normal keys that are
> down. (There are ways for a keyboard to be able to report more than 6;
> such boards are advertised as NKRO (N-Key Rollover) and it’s a gamer
> feature.)
> 
> The rollover behavior works entirely on the application side, where
> the OS and the GUI toolkit send events like “the key at position AB02
> was pressed while the left Alt is down; by the way, the character for
> this key in the current layout is x”. If the application reacts to key
> press and autorepeat events and takes the character and modifiers from
> them immediately, the “AC01 down (char a), AB05 down (char b), AC01 up
> (char a), AB05 up (char b)” sequence results in an “a then b” text
> input. But some applications (notably games) just track the whole bit
> array of keys.

But what happens after 7 consecutive down on a typical keyboard then? why 
this limitation since each key succeeds the previous one?

> Modern terminal emulators such as Kitty also make this kind of events
> available, although, for backward compatibility reasons, the
> application has to detect that this protocol extension is supported
> and opt-in to using it.
> 
> To recap: If Emacs decided to support chord input, it would not
> require any hardware modifications or OS tweaks, it would be a feature
> entirely in Emacs.

Wouldn’t it be useful if emacs implementation of user input was separated 
in a C library? it’s C right? and emacs is not the only software to 
support key sequences as commands, readline does just the same… and it 
could benefit from a such feature as well.  Moreover, emacs’ code must be, 
I guess, very stable and old (in the good sense), and must benefit from 
portability to many platforms and environments (legacy terminal (why not 
more modern extensions to it such as Kitty) + several graphical ones at 
least) and the maintainance that comes with  it, and potential future 
features (such as mouse gestures and dragging, etc.).  It could be the 
kind of library that rarely changes and is often copied in-tree and 
statically linked, just as readline is by default.  Btw emacs could be 
configured to read some config and bing some keys from the same config file as 
readline’s.

Furthermore, add to that (key chords) the support of combos (key sequences 
pressed at more or less short intervals to be considered as a complete 
sequence before to be considered over), and you would get a pretty high 
level library working for pretty much anything compatible with C, on many 
platform, with great stability, and supporting/promoting emacs’ way of 
(possibly complicated) stating/binding user input with simple readeable 
strings such as “C-x C-l l”.  A such complex library could be very useful 
to video games as well as for any application wanting a more complex 
management of user input: I guess specific GTK code doesn’t allow for 
keysequences and emacs reimplement on top of that right?

Currently I find that most used framework for that (SDL, or game engines 
such as irlicht, uses a both less powerful and more complicated way of 
binding user input than what is found in emacs or readline).

> It would not be available in some terminal
> emulators, that’s all.

well: the current (dirty and hacky) implementation, since it uses emacs’ 
primitives, works also on terminals.  But you better not press chords too 
fast or too slowly u.u that could be optionally used

A further problem is that it uses a different syntax (and a different 
function for binding keys), rather than changing/redefining/extending/
advicing the default one.

Re: New key binding syntax

[Yuri Khan]

On Fri, 5 Nov 2021 at 13:08, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> > The rollover behavior works entirely on the application side, where
> > the OS and the GUI toolkit send events like “the key at position AB02
> > was pressed while the left Alt is down; by the way, the character for
> > this key in the current layout is x”. If the application reacts to key
> > press and autorepeat events and takes the character and modifiers from
> > them immediately, the “AC01 down (char a), AB05 down (char b), AC01 up
> > (char a), AB05 up (char b)” sequence results in an “a then b” text
> > input. But some applications (notably games) just track the whole bit
> > array of keys.
>
> But what happens after 7 consecutive down on a typical keyboard then?

Technically what happens in that highly theoretical example depends on
the firmware implementation; in the USB protocol, there is provision
for the keyboard reporting “the user held down so many keys I can’t
accurately report them all”.

> why this limitation since each key succeeds the previous one?

Each key does not “succeed” the previous one. Keyboards are not only
used for text input but also for gaming and (rarely, with advanced
users) chord input, and they must be able to report at least a few
keys held down simultaneously, and the exact moment they are released.
In a game, it’s not an unusual situation that you hold down one key to
crouch, another to keep moving (crawling?) forward, and a third one to
turn left or right, while periodically pressing a fourth key to fire.
If the keyboard reports the release too early, you stand back up, and
your enemies notice you.

The limitation is about the keyboard state report having a manageable
size. With this particular format, the 8 modifiers are reported as a
bit mask in a single byte, then there is a mostly reserved byte, then
6 bytes contain the codes of keys currently held down.

Re: New key binding syntax

[Alexandre Garreau]

Le vendredi 5 novembre 2021, 09:56:26 CET Yuri Khan a écrit :
> On Fri, 5 Nov 2021 at 13:08, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > > The rollover behavior works entirely on the application side, where
> > > the OS and the GUI toolkit send events like “the key at position
> > > AB02
> > > was pressed while the left Alt is down; by the way, the character
> > > for
> > > this key in the current layout is x”. If the application reacts to
> > > key
> > > press and autorepeat events and takes the character and modifiers
> > > from
> > > them immediately, the “AC01 down (char a), AB05 down (char b), AC01
> > > up
> > > (char a), AB05 up (char b)” sequence results in an “a then b” text
> > > input. But some applications (notably games) just track the whole
> > > bit
> > > array of keys.
> > 
> > But what happens after 7 consecutive down on a typical keyboard then?
> 
> Technically what happens in that highly theoretical example depends on
> the firmware implementation; in the USB protocol, there is provision
> for the keyboard reporting “the user held down so many keys I can’t
> accurately report them all”.

so it’s like a down, b down, …, f down… and then until I release any key 
between a and f, if I press down “g”, the keyboard won’t say anything to 
the application/OS?

> > why this limitation since each key succeeds the previous one?
> 
> Each key does not “succeed” the previous one. Keyboards are not only
> used for text input but also for gaming and (rarely, with advanced
> users) chord input, and they must be able to report at least a few
> keys held down simultaneously,

wdym by “simultaneously”? “close enough in time of pressing”? or “while 
the others haven’t been released yet”?

> and the exact moment they are released.
> In a game, it’s not an unusual situation that you hold down one key to
> crouch, another to keep moving (crawling?) forward, and a third one to
> turn left or right, while periodically pressing a fourth key to fire.
> If the keyboard reports the release too early, you stand back up, and
> your enemies notice you.

I know that, and actually the best usage of key chords, key sequences and 
combos I’ve seen is indeed in FPSes.

> The limitation is about the keyboard state report having a manageable
> size. With this particular format, the 8 modifiers are reported as a
> bit mask in a single byte, then there is a mostly reserved byte, then
> 6 bytes contain the codes of keys currently held down.

what? I thought the usb kbd firmware worked by sending events that 
triggered interruptions, not that it stored keystate itself :o I thought 
keystate was saved and registered application-side, with each event

Re: New key binding syntax

[Yuri Khan]

On Fri, 5 Nov 2021 at 16:13, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> so it’s like a down, b down, …, f down… and then until I release any key
> between a and f, if I press down “g”, the keyboard won’t say anything to
> the application/OS?

As I said, it depends. (Also, I’d like to see you do that with just
your left hand.)

    q w E r t
     A s D F G
      z x C v B

> wdym by “simultaneously”? “close enough in time of pressing”? or “while
> the others haven’t been released yet”?

The latter.

> what? I thought the usb kbd firmware worked by sending events that
> triggered interruptions, not that it stored keystate itself :o I thought
> keystate was saved and registered application-side, with each event

Well, this explains your reactions. What travels over the wire is the
state (level), not the changes (edges). It is the OS, input subsystem
of the desktop, and possibly toolkit, that translates that into press,
release, and autorepeat events.

Otherwise, for example, what would happen if you held down a bunch of
keys and then unplugged the keyboard? Should the host system remember
that these keydowns originally came from device X and auto-generate
posthumous keyups for them when device X is unplugged?

(It is also the OS and the desktop’s input subsystem that interprets
keyboard layouts and turns a Shift+AB01 into a capital Z on a US
system or capital Y on a German system. But you probably knew that.)

Re: New key binding syntax

[Alexandre Garreau]

Le vendredi 5 novembre 2021, 11:03:19 CET Yuri Khan a écrit :
> On Fri, 5 Nov 2021 at 16:13, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > so it’s like a down, b down, …, f down… and then until I release any
> > key between a and f, if I press down “g”, the keyboard won’t say
> > anything to the application/OS?
> 
> As I said, it depends.

No I really didn’t understand.  You said the rollover key number changed, 
not that once it was overtook, the behavior varied.  And you said that 
number was most of time 6.  What I want to understand is what goes wrong 
then… presses unreported? releases falsely reported in some order?

> (Also, I’d like to see you do that with just
> your left hand.)

While only the left hand? with both it’s possible.

>     q w E r t
>      A s D F G
>       z x C v B

Well I have not polydactilia, so I cannot easily because I have only five 
fingers with the left hand (but I can place a finger between D F and C to 
press them with one finger, and on B and G with the remaining finger, but 
I’d need to press strong and would risk accidental releases).  But I 
neither user qwerty, and in both azerty (although then it’s difficult and I 
use the right hand only for the B) and bepo I can easily do that with both 
hands.

Anyway, I used sequential letters of the alphabet not to have to list them 
all and try to reduce confusion and example minimality, but I failed, 
keyboards cannot be simple I guess :'D

Of course, then, ideally, the user and/or app dev should take into 
consideration ergonomy and biomechanical limits into choices.

> > wdym by “simultaneously”? “close enough in time of pressing”? or
> > “while
> > the others haven’t been released yet”?
> 
> The latter.
> 
> > what? I thought the usb kbd firmware worked by sending events that
> > triggered interruptions, not that it stored keystate itself :o I
> > thought keystate was saved and registered application-side, with each
> > event
> Well, this explains your reactions. What travels over the wire is the
> state (level), not the changes (edges). It is the OS, input subsystem
> of the desktop, and possibly toolkit, that translates that into press,
> release, and autorepeat events.

For the autorepeat I could imagine, but for release I had no idea… but 
doesn’t the keyboard generates hardware events? to interrupt OS when 
there’s a change? it’s not scanned at each tick, right?

> Otherwise, for example, what would happen if you held down a bunch of
> keys and then unplugged the keyboard? Should the host system remember
> that these keydowns originally came from device X and auto-generate
> posthumous keyups for them when device X is unplugged?

I guess it should consider all keys unpressed again, since most of time 
there’s an elasticity/spring/etc. under it.

But right, I see, and 105 bits is too much I guess, I see.  I thought the 
kbd didn’t worked as a parallel port, but as a serial port, and 105 bit 
per, dunno, ms, didn’t looked like a lot.

> (It is also the OS and the desktop’s input subsystem that interprets
> keyboard layouts and turns a Shift+AB01 into a capital Z on a US
> system or capital Y on a German system. But you probably knew that.)

You guessed well) I even worked a lot on tweaking varous layouts

Re: New key binding syntax

[Yuri Khan]

On Fri, 5 Nov 2021 at 18:04, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> > > so it’s like a down, b down, …, f down… and then until I release any
> > > key between a and f, if I press down “g”, the keyboard won’t say
> > > anything to the application/OS?
> >
> > As I said, it depends.
>
> No I really didn’t understand.  You said the rollover key number changed,
> not that once it was overtook, the behavior varied.  And you said that
> number was most of time 6.  What I want to understand is what goes wrong
> then… presses unreported? releases falsely reported in some order?

Do I need to spell it? Different keyboards behave differently in that regard.

I just fired up xev(1) and held down a-s-d-f with my left hand and j-k
with my right, and tried adding ‘l’. It did not register and the
autorepeat for ‘k’ kept going on. I then released the six keys one by
one, and observed release events for each. This means my keyboard
tracks the first six non-modifier keys I press, and ignores subsequent
ones.

> For the autorepeat I could imagine, but for release I had no idea… but
> doesn’t the keyboard generates hardware events? to interrupt OS when
> there’s a change? it’s not scanned at each tick, right?

No, it doesn’t generate events. On USB, only the host can initiate
transfers[*], so it literally scans each device every once in a while.
This is why you see discussions of mouse and keyboard polling rates on
web forums.

[*]: With the exception that a USB device in low power mode is allowed
to send a wake up signal.

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That sounds nice, but using non-modifier keys as modifiers has an
  > > inherent problem: those keys are supposed to do rollover.
  > > If you press a, and while holding it down, press b, that is supposed
  > > to mean a followed by b.
  > >
  > > To make that count as "b modified by a", we would need to change how
  > > the keyboard handles the a key.

  > These days, the keyboard does not handle this kind of rollover.
  > The rollover behavior works entirely on the application side,

You're talking about implementation details; I'm talking about
the user-level behavior -- which is rollover.  The issue is,
what does it mean to press and release keys in a certain order.

If you want a-down b-down b-up a-up to act lie "b with the a modifier
key" instead of "a followed by b", making a key binding for "b with
the a modifier key" is not going to be enough.

But it might make sense to define a syntax for chords,
and a Lisp representation for them, in case we ever decide
to make them function.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Alexandre Garreau]

Le jeudi 4 novembre 2021, 03:33:58 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > What wasn’t that ever normalized/documented? it always seemed to be
>   > that “kbd” was the standard way of specifying keystrokes… was it
>   > just informal?
> It was a convenient way of specifying key sequences -- never more than
> that.

oh ok, so switching to being compatible/displaying like something more 
standard and widespread such as “Ctrl+X Ctrl+C” (or shorter C+x C+c) 
wouldn’t be out of question?

>   > I always wondered: if one day emacs was to allow to gracefully
>   > support
>   > key-chords [0] (that is, using any key other as a “modifier”, so
>   > that you could press a and b at the same time and it would be a
>   > special keystrokes, which makes expressivity of keystrokes increase
>   > factorially with length instead of exponentially), at least in
>   > certain configurations.
> That sounds nice, but using non-modifier keys as modifiers has an
> inherent problem: those keys are supposed to do rollover.
> If you press a, and while holding it down, press b, that is supposed
> to mean a followed by b.

isn’t that specific to the terminal then? isn’t there some (maybe lower 
level) way of distinguishing key presses and key releases?

> To make that count as "b modified by a", we would need to change how
> the keyboard handles the a key.

it seems to use some dirty hacks not to have to modify the way keyboard is 
managed, by using some small timespan between keypresses, actually that 
could as well be used for a different thing: triple-SPC and double-SPC for 
hitting some key (such as space) many times successively rapidly, just 
like double-mouse-1 and triple-mouse-1

I understand gtk may not support this but I guess something lower level 
(at least SDL provides it) permits to guess it by distinguishing between 
the key-down event and the key-up event.

>   > That feature (actually, dirty hack, for now, but the author consider
>   > emacs to be misdesigned apparently, according implementation notes)
>   > is even advertised on emacs’ webpage through the emacsrock serie
>   > [1]
> 
> Sorry, I can't make sense of that.  What is "emacsrock"?  What does
> "[1]" refer to?  When you say "on Emacs' webpage", what exact URL do
> you mean?

oh damn I forgot the footnote! >< here it is:

http://emacsrocks.com/e07.html

Emacs Rock is serie of videos presenting some unique features/extensions 
of emacs:

http://emacsrocks.com/ (it’s hosted on youtube and github but does 
recommand to use youtube-dl instead (but says nothing about github, but 
well, it works without js and the repos are meant as a read-only hosting 
place so I guess it’s ok))

it is advertised on emacs main webpage that is gnu.org/s/emacs

Re: New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > oh ok, so switching to being compatible/displaying like something more 
  > standard and widespread such as “Ctrl+X Ctrl+C” (or shorter C+x C+c) 
  > wouldn’t be out of question?

In principle, we could adopt whatever syntax we want, as long as we
keep the old code working.

Introducing `kbd' enabled us to support a new, incompatible syntax
alongside the original syntax.  If we decide now on a syntax that is
not upward compatible with `kbd', we could support it using a new
function, perhaps `key'.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: New key binding syntax

[Emanuel Berg via Emacs development discussions.]

Richard Stallman wrote:

> Introducing `kbd' enabled us to support a new, incompatible
> syntax alongside the original syntax. If we decide now on
> a syntax that is not upward compatible with `kbd', we could
> support it using a new function, perhaps `key'.

Uhm, excuse my ignorance but why should we have so many?

You mention `kbd' and hints at a new "key" ... and in my
config files I have, e.g.

  (global-set-key "\C-ok" #'end-of-buffer)
  (global-set-key  [C-i]  #'new-message)

That is 3, would be 4, and I'm not sure I exhausted the list
even ...

So not a rhetorical question, why isn't there just _one_
representation in Emacs and then the outside world, be it the
WM or terminal emulator or virtual terminal or terminal
multiplexer or DE or Window System or OS - all that can deal
with it, and/or let Emacs deal with it any way they like?

Only from here, it would always look the same?

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : New key binding syntax

[Drew Adams]

>> Have a look at the kbd-valid-p doc string on the 
>> current trunk for a definition.
> 
> I've included that text below, because now is the time
> for people to look at and comment on it.
> 
> Should the syntax Emacs adopts for the next 20 years be
> this one?  This one with some changes?  Any other proposal?
> 
> If we use this syntax, the text we use to define it in
> the Emacs Lisp Ref Manual should cover valid cases not
> mentioned in this text.  We don't use them in normal
> Emacs bindings, but they are valid so they should be
> documented.


You didn't get much of a response to your request
for opinions about this.  FWIW, here's my opinion
on the key-sequence description syntax we should use.

___

This is about use cases where we now use `kbd'.  This
is typically about using (kbd ...) as input to things
like `define-key'.

This is not particularly about how some explanatory
text in a manual, for example, can refer to things like
inputs in general or about message outputs.  For that,
I think the currently used representation is fine.
That can of course include the use of key descriptions,
such as are accepted by `kbd'.  It also includes text
such as `M-x some-command'.

And it even includes informal text such as "Type M-x
foobar RET".  (Notice that "foobar" here informally
stands for typing the sequence "f SPC o SPC o SPC b SPC
a SPC r", but "RET" stands for hitting just that key,
not for hitting the keys "R", "E", and "T".)

I say this deciding about key-description syntax is not
about that, in particular, to distinguish the use of
whitespace.  Informal description of user input and
output messages is something different from, and more
inclusive and forgiving than, the precise syntax of
key-sequence descriptions.

For simplicity I'll generally refer to the
key-description syntax I prefer as "kbd" syntax,
because it's essentially what `kbd' accepts.

Some (Stefan K in particular) have pointed out that the
current implementation of `kbd' accepts some
seldom-used or outlier syntax possibilities, and `kbd'
might have some bugs or undesirable features.

I don't include those in the syntax I prefer.  If we
ever get to that point, that is, if we ever get general
agreement on the "normal", syntax that `kbd' accepts as
what we want for the future, then at that point we can
discuss any of the odd or arcane possibilities that
`kbd' also accepts.

___


1. Whitespace should be allowed arbitrarily for
separation in the key-description syntax.  I believe
this is already the case (at least for space chars),
but in any case it should be.

You should be able to use "a    b  c", or "a b
c" (including the newline), or "  a b  c   ", or any
other syntax where any number of SPC, TAB, and newline
chars separate keys in a key sequence.  (No, I wouldn't
allow unusual Unicode whitespace chars - no need; these
are just separators, for our convenience.)

IOW, I don't agree with Lars's preference of allowing
only a single SPC char as separator; I agree with John
Yates here.  And I'd go beyond SPC to allow newline and
TAB, but that's not important - just a nice-to-have /
why-not.

2. A space char in a key sequence should be represented
as SPC in a key description, not as a literal space
char.  I see _no_ advantage to having space chars
represent themselves literally, as opposed to using the
name of the key that's associated with, and by default
inserts, that char: (kbd "SPC").

Same for newline (C-j) and TAB (C-i) keys. To represent
a TAB key, use (kbd "TAB") or (kbd "C-i"); to represent
a newline, use C-j: (kbd "C-j").  We'd just be asking
for trouble, and confusing users _more_ (not less), if
we started using " " instead of "SPC" - without gaining
anything.

(And yes, the key `<tab>' is different from the key
`TAB', though sometimes the one gets translated to the
other for binding lookup.)

(Whether and how weallow unicode, octal, or other
representations for chars in key descriptions is
another question.  I don't have an answer/preference
for that now, but maybe it should be discussed at some
point.)

3. Personally, I don't feel a need to allow the
argument to `kbd' to be used on its own (e.g., passed
to `define-key" or its replacement), in place of using
(kbd ARG) - let alone feel a need to prescribe that.

I don't see that as helping anyone.  Just as for using
" " instead of "SPC", I expect that doing that just
asks for trouble and sows confusion, without any gain.
This is just a guess; I could maybe be convinced
otherwise, but so far I haven't seen any good argument.

4. I agree that if `kbd' has some anomalies, as Stefan
K pointed out, we can remove them from any new,
replacement syntax we define.

I don't care much whether we use a new function (e.g.
`key') or we just change `kbd' itself, purifying it of
anomalies.  The former is maybe easier and cleaner, to
let `kbd' continue to go its merry way for backward
compatibility.

5. I don't think we should impose a single ordering of
modifiers.  But I do think we should have a convention
that specifies a preferred order.

IOW, let's separate what you _can_ use (any modifier
order) from what we recommend you _do_ use.  For the
recommended order, let's stick with what we've already
recommended - which should be the same order that Emacs
itself uses in its Help output.  E.g., `C-M-', not
`M-C-'.  But again, this isn't very important - it's
just a convention that makes things more consistent,
hence easier to read and digest.

6. The correspondence between the syntax you pass to
`kbd' and the syntax that Emacs Help uses is very
important, IMO.  Emacs and users (including users of
Elisp) should talk about keys using the same syntax,
as much as possible.

7. I'm in favor of letting `kbd' and Help descriptions
drop the use of angle brackets altogether.  I've done
that, and I haven't encountered any problems or
contradictions from doing it.  `kbd' (or `key' or
whatever) can and should accept both angle-bracketed
and "naked" syntax (no brackets), with no difference in
behavior.  Again, I've been doing this for decades now.

FWIW (but I don't care how Emacs itself does it), I use
function `naked' instead of function `kbd', and
`naked-key-description' instead of `key-description'.
Emacs itself wouldn't need two sets of functions.

Function `naked' indifferently accepts either naked or
angle-bracketed syntax as input.

(To reproduce Emacs bug #12535 faithfully (!) it also
accepts an optional Boolean arg ANGLES, which forces
the bugged behavior, e.g., makes the input "M-<TAB>"
output [M-TAB] instead of the correct output
[134217737].)

Other NaKeD functions likewise accept an optional
ANGLES arg.  With non-nil arg, `naked-key-description'
does just what `key-description' does (otherwise it
outputs naked key descriptions).  Likewise
`naked-read-kbd-macro' and `naked-edmacro-parse-keys':
an optional arg gives the current bracketed Emacs
behavior.

But my point here is that Emacs itself does not need
angle-bracket syntax - at all.  (Eli claims otherwise,
but I've seen no counter-example so far.)  That noise
was introduced gratuitously in Emacs 21, I believe.  

`C-x toto' unequivocally means the same thing as `C-x
<toto>'.  And the few ASCII control chars with names
that we accept (RET, SPC, ESC, etc.) don't invalidate
this proposition.  (And yes, bug #12535 is a bug.)

#7 here is apparently heretical, and I don't expect it
to be accepted.  But I feel obliged to mention it once
more, since the question has been raised of the syntax
we want for key descriptions.  There really is no need
for angle brackets.  Really.  So Occam says drop 'em.
(Or show a real case where they're actually needed.)

Description:
https://www.emacswiki.org/emacs/NaKeD

Code:
 https://www.emacswiki.org/emacs/download/naked.el

___

As for the new syntax proposal that RMS asked about,
from the `kbd-valid-p' doc string: seems like confusion
of use and mention.

(I don't know what `kbd-valid-p' is really for, but I'm
guessing it's for testing the validity of a key
description, e.g. what `kbd' or its replacement should
accept as a valid arg, i.e., as an arg that validly
describes a possible key sequence.)

It confuses statements of what a key sequence is with
what the syntax of a key(-sequence) description is,
i.e., what constitutes a "valid key sequence" (which is
a sequence of keys) versus what constitutes a valid
key-sequence description for use in code and Help (e.g.
as arg to `kbd').

It's OK in the doc to talk about the "key sequence `C-x
C-f'", because there we're _using_ the term "key
sequence" to talk about a key sequence, which itself is
represented by the description `C-x C-f'.  We're not
talking about the text/syntax "C-x C-f" there; we're
talking about the sequence of keys that that
description represents.

But when we're talking about defining/specifying valid
syntax for key descriptions, we shouldn't say we're
talking about defining which _key sequences_ are valid.

\"S o m\" is _not_ a key sequence.  It's not a
"sequence of the keys 'S', 'o' and 'm'".  It's
presumably (a proposal for) a valid key-sequence
description string.

___

One opinion.  I agree with Richard that we should hear
more opinions.  Let's get the right dough before baking.

Re: [External] : New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I agree with your points 1, 2, 4, 5 and 6.

  > 7. I'm in favor of letting `kbd' and Help descriptions
  > drop the use of angle brackets altogether.

I agree that that would be good -- provided no ambiguity results.
Does anyone see a concrete problem with this?

  > 3. Personally, I don't feel a need to allow the
  > argument to `kbd' to be used on its own (e.g., passed
  > to `define-key" or its replacement), in place of using
  > (kbd ARG) - let alone feel a need to prescribe that.

To allow the new syntax in arguments to old functions such as
`define-key'  would be desirable if it doesn't cause problems.
But I think it would lead to incompatibilities or conflicts,
where an argument has one meaning as a key sequence (old style)
and another as an argument to `kbd', so I think we can't do it.

I suggest defining new functions to replace `define-key' and friends,
that will take a new-style key sequence as argument and will NOT accept
an old-style key sequence.

  > \"S o m\" is _not_ a key sequence.  It's not a
  > "sequence of the keys 'S', 'o' and 'm'".

I can't make head or tail of that.  Why the backslashes
before those doublequotes?

With the default Emacs key bindings, S o m is not a valid
key sequence, because S is not a prefix key.
But it COULD be a valid key sequence if you defined S
as a prefix key, then defined S o as a prefix key.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : New key binding syntax

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > 7. I'm in favor of letting `kbd' and Help descriptions
>   > drop the use of angle brackets altogether.
>
> I agree that that would be good -- provided no ambiguity results.
> Does anyone see a concrete problem with this?

My problem is not technical but social: we are used to seeing M-<return>
so it might be jarring to suddenly see M-return.  Isn't the latter also
harder to read?

PS. Of course, if we cared deeply about readability we would write instead:

        Alt + Return

    But even me, a radical, hesitate to propose such far-reaching changes.
    But in the abstract I think it would be both desirable and TRT.

RE: [External] : New key binding syntax

[Drew Adams]

> >   > 7. I'm in favor of letting `kbd' and Help descriptions
> >   > drop the use of angle brackets altogether.
> >
> > I agree that that would be good -- provided no ambiguity results.
> > Does anyone see a concrete problem with this?
> 
> My problem is not technical but social: we are used to seeing M-<return>
> so it might be jarring to suddenly see M-return.  Isn't the latter also
> harder to read?
> 
> PS. Of course, if we cared deeply about readability we would write instead:
> 
>         Alt + Return
> 
> But even me, a radical, hesitate to propose such far-reaching changes.
> But in the abstract I think it would be both desirable and TRT.

(Thanks for considering this.)

It's simple to support both with and without angle
brackets, as I mentioned.

Of course, at least in what I've done, the choice
is made by whoever is coding the use of (calls to)
the function accepting the key-description syntax
(function `naked' in my case; function `kbd' or
`key' or whatever, if this gets done in Emacs itself.

It might additionally be possible and helpful to
let users themselves make such a choice.  Dunno.

Personally, I'd expect movement away from bothering
with angle brackets, as just extra noise.  But for
now, at least, there's no reason not to support use
of both with and without brackets.  Letting users
control which syntax they see (e.g. in *Help*) might
be more trouble than it would be worth.

Re: [External] : New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My problem is not technical but social: we are used to seeing M-<return>
  > so it might be jarring to suddenly see M-return.  Isn't the latter also
  > harder to read?

I am not sure which one is easier to read.

I also wonder if there could be confusion between M-RET and M-<return>
if the former can be written M-ret and the latter can me written M-return.

I don't see how to come up with an answer that is rigorously correct,
for these questions.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: [External] : New key binding syntax

[Drew Adams]

> I also wonder if there could be confusion between M-RET
> and M-<return> if the former can be written M-ret and
> the latter can me written M-return.

There's no confusion.  (And the former cannot be written
M-ret.)

(naked "M-RET")    -> [134217741] (Meta + ASCII RET)
(naked "M-return") -> [M-return]  (Meta + function key
                                   return, aka <return>) 
(naked "M-ret")    -> [M-ret]     (Meta + a function key
                                   named ret, aka <ret>) 

With angle brackets, the results are identical (and the
same as what `kbd' gives you):

(naked "M-<RET>")    -> [134217741]
(naked "M-<return>") -> [M-return]
(naked "M-<ret>")    -> [M-ret]

Vanilla Emacs already treats the ASCII control chars
specially (with the exception of TAB (C-i) - see bug
#12535).  That's so with and without modifiers.

`naked' does the same thing.  It even lets you
manifest bug #12535, if you really want bug-for-bug
compatibility.  (Just provide a non-nil second arg
ANGLES, to get exactly the (bugged) `kbd' behavior.)

(naked "TAB")     -> "	"  (that's a TAB char)
(naked "<TAB>")   -> "	"  (same thing)
(naked "<TAB>" t) -> [TAB] (bug #12535)
(naked "<tab>")   -> [tab]

> I don't see how to come up with an answer that is
> rigorously correct,for these questions.

Try naked.el, and see if you find a case that is not
rigorously correct.  None has been presented, so far.

https://www.emacswiki.org/emacs/download/naked.el

Re: [External] : New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I also wonder if there could be confusion between M-RET
  > > and M-<return> if the former can be written M-ret and
  > > the latter can me written M-return.

  > There's no confusion.  (And the former cannot be written
  > M-ret.)

As long as we keep the rule that the special control character names
must be upper case, and  function key names must be lower-case,
I think it will avoid confusion.

I think someone proposed to eliminate that rule.

  > PS. Of course, if we cared deeply about readability we would write instead:

  >         Alt + Return

If we stick to that rule, we would want to write `alt' and `return'.
Allowing spaces inside a single key name would definitely be confusing
as long as space separates keys in a key sequence.  But we could allow
`alt-return' as an alternative to `a-return'.

I see no benefit in allowing `+' as a synonym for `-'.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le mardi 16 novembre 2021, 05:05:27 CET Richard Stallman a écrit :
> I see no benefit in allowing `+' as a synonym for `-'.

I already proposed that too actually, so several people are proposing it

Most software use that convention, and + is more understandable for that 
meaning to most people.  It’s no way less useful than saying “GNU+Linux” 
instead of “GNU-Linux”…

Re: [External] : New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Most software use that convention,

Not in my experience.  I have never seen + used to indicate
keyboard modifier keys.  Always C-x, never C+x.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : New key binding syntax

[Yuri Khan]

On Thu, 18 Nov 2021 at 10:54, Richard Stallman <rms@gnu.org> wrote:

>   > Most software use that convention,
>
> Not in my experience.  I have never seen + used to indicate
> keyboard modifier keys.  Always C-x, never C+x.

Never C+x, because it’s spelled Ctrl+X. And Alt+X. And the letters are
capitals because Shift is spelled out explicitly.

Keys are not ASCII characters.

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le jeudi 18 novembre 2021, 06:01:13 CET Yuri Khan a écrit :
> On Thu, 18 Nov 2021 at 10:54, Richard Stallman <rms@gnu.org> wrote:
> >   > Most software use that convention,
> > 
> > Not in my experience.  I have never seen + used to indicate
> > keyboard modifier keys.  Always C-x, never C+x.
> 
> Never C+x, because it’s spelled Ctrl+X. And Alt+X. And the letters are
> capitals because Shift is spelled out explicitly.
> 
> Keys are not ASCII characters.

They can be related.  You could set up a keymap layout where each key is 
capital, and pressing shift makes them lowercase, at the opposite of the 
normal working, or even something more weird.

So the fact to capitalize keys makes the key sequence transcription 
strictly less powerful

But it can be useful, mostly because capitals, alone, are often considered 
easier to read (especially when your sight starts to degrade with age)

Re: [External] : New key binding syntax

[Yuri Khan]

On Thu, 18 Nov 2021 at 21:36, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> > Keys are not ASCII characters.
>
> They can be related.  You could set up a keymap layout where each key is
> capital, and pressing shift makes them lowercase, at the opposite of the
> normal working, or even something more weird.

Hey, millions of people deal daily with layouts where pressing the key
Q yields the character й. In Emacs, one has to mess with
function-key-map so й translates to q which buries Dired. In an ideal
world, Dired would bind not the character q but the key Q, and it
would just work no matter the layout.

Re: [External] : New key binding syntax

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 18 Nov 2021 21:59:28 +0700
> Cc: Stefan Kangas <stefankangas@gmail.com>, Richard Stallman <rms@gnu.org>,
>  Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Hey, millions of people deal daily with layouts where pressing the key
> Q yields the character й. In Emacs, one has to mess with
> function-key-map so й translates to q which buries Dired. In an ideal
> world, Dired would bind not the character q but the key Q, and it
> would just work no matter the layout.

How do you work in Emacs with a keyboard that generates Cyrillic
characters?  All the commands are in English, responses to prompts are
also in English, etc.  Don't you switch the keyboard language to
English anyway?

IOW, it sounds like the path to the "ideal world" is a tad longer than
just binding keys in Dired.

Re: [External] : New key binding syntax

[Yuri Khan]

On Thu, 18 Nov 2021 at 22:22, Eli Zaretskii <eliz@gnu.org> wrote:

> How do you work in Emacs with a keyboard that generates Cyrillic
> characters?  All the commands are in English, responses to prompts are
> also in English, etc.  Don't you switch the keyboard language to
> English anyway?

I do, when I need to type text in English. Shell commands count as
English text. Single-key bindings in Dired, Ctrl+letter and Alt+letter
sequences do not. In Gedit, the key Ctrl+S saves the document no
matter whether pressing the key S would produce the character s or the
character ы.

> IOW, it sounds like the path to the "ideal world" is a tad longer than
> just binding keys in Dired.

In Emacs, it is. For historical terminal-related reasons.

Re: [External] : New key binding syntax

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 18 Nov 2021 22:39:06 +0700
> Cc: Alexandre Garreau <galex-713@galex-713.eu>, Stefan Kangas <stefankangas@gmail.com>, 
> 	Richard Stallman <rms@gnu.org>, Drew Adams <drew.adams@oracle.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Thu, 18 Nov 2021 at 22:22, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > How do you work in Emacs with a keyboard that generates Cyrillic
> > characters?  All the commands are in English, responses to prompts are
> > also in English, etc.  Don't you switch the keyboard language to
> > English anyway?
> 
> I do, when I need to type text in English. Shell commands count as
> English text. Single-key bindings in Dired, Ctrl+letter and Alt+letter
> sequences do not.

So you deliberately switch to Cyrillic when you in Dired?

> In Gedit, the key Ctrl+S saves the document no matter whether
> pressing the key S would produce the character s or the character ы.

Why is that an Emacs problem?  E.g., on MS-Windows this happens to me
in any program.  So maybe your accusations are misdirected, and should
be redirected to the OS handling of the keyboard?

> > IOW, it sounds like the path to the "ideal world" is a tad longer than
> > just binding keys in Dired.
> 
> In Emacs, it is. For historical terminal-related reasons.

Nonsense.

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le jeudi 18 novembre 2021, 15:59:28 CET Yuri Khan a écrit :
> On Thu, 18 Nov 2021 at 21:36, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > > Keys are not ASCII characters.
> > 
> > They can be related.  You could set up a keymap layout where each key
> > is capital, and pressing shift makes them lowercase, at the opposite
> > of the normal working, or even something more weird.
> 
> Hey, millions of people

I’d say millions if it was less than 10 millions, here I’d rather say 
hundreds of millions, or tenths of billion

> deal daily with layouts where pressing the key
> Q yields the character й.

Then it’s the key Й, not the key Q.  Qwerty is not in any way “more basic” 
or “more low level” than Йцукен.  What’s lower level are scancode 
(arbitrary numbers, depending of position on keyboard + whether it’s 
pressed or released + history), translated to keycodes (not depending of 
whether it’s pressed or released, used by keymap layouts definitions), 
translated, by a given keyboard layout (be it US qwerty, US dvorak, 
programmer dvorak, standard russian йцукенп, polyglot reactionary йцукен 
(what I use), french azerty, belgian azerty, french bépo, german qwertz, 
swiss qwertz, etc.) to keysyms (which *are* characters, such as Q or Й, 
most of the time, but also can be other actions such as XF86AudioPlay)

> In Emacs, one has to mess with
> function-key-map so й translates to q which buries Dired.

What about quail?

Imho, when you are too often used to use a non-latin layout, using an 
input-method may be useful, as these will translate keys to write text, 
but not to enter keybindings

> In an ideal
> world, Dired would bind not the character q but the key Q, and it
> would just work no matter the layout.

You cannot do that.  There is no “key Q” independent from a character, 
whatever the layout is.  So either you would use quail and/or input-method 
to parametrize how emacs would translate keys, either (and that has been 
stated as desirable but complex in the past) emacs would use lower-level 
functions of terminal/X (just as, say, i3wm does) to use keycodes… which 
are *not* related to keys, hence are by default not related to letters/
characters, but only to a position on keyboard, so they *cannot* be 
mnemonic just as emacs does by default… or then, you would have to 
*choose* manually one layout to take your key positions from, and 
translate keysyms to keycodes… which is pretty unusual and esoteric, but 
could be done as well from a keymap layout definition (find yours in 
something such as /usr/share/X11/xkb/symbols/ru)

Re: [External] : New key binding syntax

[Yuri Khan]

On Thu, 18 Nov 2021 at 22:32, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> > deal daily with layouts where pressing the key
> > Q yields the character й.
>
> Then it’s the key Й, not the key Q.

No, it is the key Q. When I switch layouts, I don’t magically lose 33
keys, gain 33 different keys, and have a few other keys move around.
The comma key stays at AB08 even though the comma character is on
Shift+AB10.

> Qwerty is not in any way “more basic” or “more low level” than Йцукен.

In a way, it is.

> What’s lower level are scancode
> (arbitrary numbers, depending of position on keyboard + whether it’s
> pressed or released + history), translated to keycodes (not depending of
> whether it’s pressed or released, used by keymap layouts definitions),
> translated, by a given keyboard layout (be it US qwerty, US dvorak,
> programmer dvorak, standard russian йцукенп, polyglot reactionary йцукен
> (what I use), french azerty, belgian azerty, french bépo, german qwertz,
> swiss qwertz, etc.) to keysyms (which *are* characters, such as Q or Й,
> most of the time, but also can be other actions such as XF86AudioPlay)

I know all that. Still, in a dual-script environment, Latin is the
primary script and people use that when referring to a key.

> What about quail?
>
> Imho, when you are too often used to use a non-latin layout, using an
> input-method may be useful, as these will translate keys to write text,
> but not to enter keybindings

Quail is a solution if Emacs is your desktop environment. For me,
Emacs is an application, and I use XKB to handle layouts. Using Emacs
input methods in Emacs but XKB on the rest of the desktop would break
my muscle memory, as I’d have to switch layouts with Ctrl+\ in Emacs
but with a dedicated key everywhere else.

> > In an ideal
> > world, Dired would bind not the character q but the key Q, and it
> > would just work no matter the layout.
>
> You cannot do that.  There is no “key Q” independent from a character,
> whatever the layout is.  So […] you would have to
> *choose* manually one layout to take your key positions from, and
> translate keysyms to keycodes… which is pretty unusual and esoteric, but
> could be done as well from a keymap layout definition (find yours in
> something such as /usr/share/X11/xkb/symbols/ru)

It’s not unusual and not esoteric. When I press Ctrl+A with the
ru(winkeys) layout active, I get an X KeyPress event with a keycode of
38 (corresponding to AC01), a keysym of 0x61 (‘a’), and a modifier
state with the Ctrl bit set. Clearly, something, somewhere, consults
the primary layout.


So, why am I raising this in this thread? It Would Be Nice if Emacs
some day let keymaps bind either Keys or Characters, whichever makes
more sense for each binding. And while we are discussing a key binding
syntax for the next 20 years, It Would Be Nice if this syntax
permitted extension in that direction when the time comes.

Re: [External] : New key binding syntax

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 18 Nov 2021 23:20:23 +0700
> Cc: Drew Adams <drew.adams@oracle.com>, Stefan Kangas <stefankangas@gmail.com>,
>  Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> So, why am I raising this in this thread? It Would Be Nice if Emacs
> some day let keymaps bind either Keys or Characters, whichever makes
> more sense for each binding. And while we are discussing a key binding
> syntax for the next 20 years, It Would Be Nice if this syntax
> permitted extension in that direction when the time comes.

As usual, patches for such a feature will be very welcome.  As usual,
nothing will probably happen in this department unless we do get
patches, since past discussions revealed this issue has some
underwater rocks that need to be carefully negotiated.

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le jeudi 18 novembre 2021, 17:20:23 CET Yuri Khan a écrit :
> On Thu, 18 Nov 2021 at 22:32, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > > deal daily with layouts where pressing the key
> > > Q yields the character й.
> > 
> > Then it’s the key Й, not the key Q.
> 
> No, it is the key Q. When I switch layouts, I don’t magically lose 33
> keys, gain 33 different keys, and have a few other keys move around.
> The comma key stays at AB08 even though the comma character is on
> Shift+AB10.

What do you mean? how does that concreticizes? how do you observe that?

> > Qwerty is not in any way “more basic” or “more low level” than Йцукен.
> 
> In a way, it is.

I don’t believe it, and would expect very strong and concrete evidence for 
that.

> > What’s lower level are scancode
> > (arbitrary numbers, depending of position on keyboard + whether it’s
> > pressed or released + history), translated to keycodes (not depending
> > of whether it’s pressed or released, used by keymap layouts
> > definitions), translated, by a given keyboard layout (be it US
> > qwerty, US dvorak, programmer dvorak, standard russian йцукенп,
> > polyglot reactionary йцукен (what I use), french azerty, belgian
> > azerty, french bépo, german qwertz, swiss qwertz, etc.) to keysyms
> > (which *are* characters, such as Q or Й, most of the time, but also
> > can be other actions such as XF86AudioPlay)
> I know all that. Still, in a dual-script environment, Latin is the
> primary script and people use that when referring to a key.

That’s sad.

> > What about quail?
> > 
> > Imho, when you are too often used to use a non-latin layout, using an
> > input-method may be useful, as these will translate keys to write
> > text,
> > but not to enter keybindings
> 
> Quail is a solution if Emacs is your desktop environment. For me,
> Emacs is an application, and I use XKB to handle layouts. Using Emacs
> input methods in Emacs but XKB on the rest of the desktop would break
> my muscle memory, as I’d have to switch layouts with Ctrl+\ in Emacs
> but with a dedicated key everywhere else.

Yeah you would have to stop use xkb, and define only one X layout, that 
would be your most used latin layout, and start doing everything with 
emacs… that’s something I, too, have not yet started to do…

But please notice if you do Ctrl+ any letter that’s cyrillic or arabic in 
emacs, you get for instance C-ы or C-لا (I bound that last to C-g, because 
I find extremely beautiful that a language have a layout whose central key 
means “no”, so you can type “Ctrl+no”), nothing is stopping you from doing 
that.  Actually, if emacs really wanted to use mnemotechnic bindings in 
all circumstances, we should have some keymap for each script… but nobody 
is doing that, and I really think, too, that ideally we should bind 
commands to keycodes, not to keysyms, because it works best and more 
logically in a multilingual environment, and it would help move emacs into 
the direction of purely modal editing (such as what spacemacs succeedingly 
promotes)

> > > In an ideal
> > > world, Dired would bind not the character q but the key Q, and it
> > > would just work no matter the layout.
> > 
> > You cannot do that.  There is no “key Q” independent from a character,
> > whatever the layout is.  So […] you would have to
> > *choose* manually one layout to take your key positions from, and
> > translate keysyms to keycodes… which is pretty unusual and esoteric,
> > but could be done as well from a keymap layout definition (find yours
> > in something such as /usr/share/X11/xkb/symbols/ru)
> 
> It’s not unusual and not esoteric. When I press Ctrl+A with the
> ru(winkeys) layout active, I get an X KeyPress event with a keycode of
> 38 (corresponding to AC01), a keysym of 0x61 (‘a’), and a modifier
> state with the Ctrl bit set. Clearly, something, somewhere, consults
> the primary layout.

It’s not a primary layout, I suspect it’s only the “last used layout” 
that’s latin (possibly it could be dvorak, or parts of qwertz, azerty or 
bépo).  I strongly suspect this is a bug, and that working derives from 
some interaction nobody ever consciously designed

> So, why am I raising this in this thread? It Would Be Nice if Emacs
> some day let keymaps bind either Keys or Characters,

And Keys should be specified by number, that’s the only neutral, portable 
and long-term stable solution there

> whichever makes
> more sense for each binding. And while we are discussing a key binding
> syntax for the next 20 years, It Would Be Nice if this syntax
> permitted extension in that direction when the time comes.

I totally agree

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le jeudi 18 novembre 2021, 04:52:18 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Most software use that convention,
> 
> Not in my experience.  I have never seen + used to indicate
> keyboard modifier keys.  Always C-x, never C+x.

Are you thinking of mostly terminal applications…? what software does that 
except emacs, nano, and readline-based software? I can’t find really

All of what I see right now: KMail, KWin, Firefox, Telegram, Modem-
Manager-GUI, Transmission, documentation of mpv… really, all of them, and 
only that… that’s the only thing I can find…

But it’s Ctrl+X (or Ctrl + X sometimes, unfortunately (it’s ambiguous)), 
not C+x

Re: [External] : New key binding syntax

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Most software use that convention,
>
> Not in my experience.  I have never seen + used to indicate
> keyboard modifier keys.  Always C-x, never C+x.

Here are some prominent examples:

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
https://help.gnome.org/users/gedit/stable/gedit-shortcut-keys.html.en
https://help.libreoffice.org/3.3/Writer/Shortcut_Keys_for_Writer
https://docs.gimp.org/2.10/en/gimp-concepts-shortcuts.html

Re: [External] : New key binding syntax

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Not in my experience.  I have never seen + used to indicate
  > > keyboard modifier keys.  Always C-x, never C+x.

  > Here are some prominent examples:

  > https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
  > https://help.gnome.org/users/gedit/stable/gedit-shortcut-keys.html.en
  > https://help.libreoffice.org/3.3/Writer/Shortcut_Keys_for_Writer
  > https://docs.gimp.org/2.10/en/gimp-concepts-shortcuts.html

How bizarre they are!

I am against making this change in Emacs.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le vendredi 19 novembre 2021, 05:44:54 CET Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > Not in my experience.  I have never seen + used to indicate
>   > > keyboard modifier keys.  Always C-x, never C+x.
>   > 
>   > Here are some prominent examples:
>   > 
>   > https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-fire
>   > fox-tasks-quickly
>   > https://help.gnome.org/users/gedit/stable/gedit-shortcut-keys.html.
>   > en https://help.libreoffice.org/3.3/Writer/Shortcut_Keys_for_Writer
>   > https://docs.gimp.org/2.10/en/gimp-concepts-shortcuts.html
> 
> How bizarre they are!
> 
> I am against making this change in Emacs.

Why? everybody does that now and that’s strictly more recognizable for 
most of people (especially newcomers) nowadays

Re: [External] : New key binding syntax

[Po Lu]

Alexandre Garreau <galex-713@galex-713.eu> writes:

> Why? everybody does that now and that’s strictly more recognizable for 
> most of people (especially newcomers) nowadays

Terms like "keymap", "global-set" and such are unlikely to be familiar
to that group of people.  Most people however can intuit the meaning of
keys such as `C-i' to mean "Control-I".

Re: [External] : New key binding syntax

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Fri, 19 Nov 2021 07:05:12 +0100
> Cc: Stefan Kangas <stefankangas@gmail.com>, drew.adams@oracle.com
> 
> > I am against making this change in Emacs.
> 
> Why? everybody does that now and that’s strictly more recognizable for 
> most of people (especially newcomers) nowadays

Does that mean you want us to go through all our manuals and the
tutorial, and change C-x and C-M-y into Ctrl+x and Ctrl+Alt+y?  And
then change all the key-binding APIs to accept the above notation as
well?  Because if we don't do that, there will be two very different
ways of specifying key sequences, and that will confuse newcomers even
more.

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le vendredi 19 novembre 2021, 08:40:14 CET Eli Zaretskii a écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Date: Fri, 19 Nov 2021 07:05:12 +0100
> > Cc: Stefan Kangas <stefankangas@gmail.com>, drew.adams@oracle.com
> > 
> > > I am against making this change in Emacs.
> > 
> > Why? everybody does that now and that’s strictly more recognizable for
> > most of people (especially newcomers) nowadays
> 
> Does that mean you want us to go through all our manuals and the
> tutorial, and change C-x and C-M-y into Ctrl+x and Ctrl+Alt+y?  And
> then change all the key-binding APIs to accept the above notation as
> well?  Because if we don't do that, there will be two very different
> ways of specifying key sequences, and that will confuse newcomers even
> more.

Yes, and as I said it would be even more nice to have a special syntax/
command in texinfo to specify keysequences, so they can be 
programmatically all be changed very easily, in case the user rebinds 
them, so not only emacs’ C-h is updated, but the info manual as well (and 
that could be useful as well for any software whose keys can and commonly 
are rebound)

So it would not only be useful to substitute a - with a +, but also whole 
key prefixes or keysequences with others

Re: [External] : New key binding syntax

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Cc: emacs-devel@gnu.org, rms@gnu.org, stefankangas@gmail.com, drew.adams@oracle.com
> Date: Fri, 19 Nov 2021 12:33:32 +0100
> 
> > > Why? everybody does that now and that’s strictly more recognizable for
> > > most of people (especially newcomers) nowadays
> > 
> > Does that mean you want us to go through all our manuals and the
> > tutorial, and change C-x and C-M-y into Ctrl+x and Ctrl+Alt+y?  And
> > then change all the key-binding APIs to accept the above notation as
> > well?  Because if we don't do that, there will be two very different
> > ways of specifying key sequences, and that will confuse newcomers even
> > more.
> 
> Yes, and as I said it would be even more nice to have a special syntax/
> command in texinfo to specify keysequences, so they can be 
> programmatically all be changed very easily, in case the user rebinds 
> them, so not only emacs’ C-h is updated, but the info manual as well (and 
> that could be useful as well for any software whose keys can and commonly 
> are rebound)

Well, you certainly expect others to do a lot of work here.

Re: [External] : New key binding syntax

[Alexandre Garreau]

Le vendredi 19 novembre 2021, 13:43:02 CET Eli Zaretskii a écrit :
> > From: Alexandre Garreau <galex-713@galex-713.eu>
> > Cc: emacs-devel@gnu.org, rms@gnu.org, stefankangas@gmail.com,
> > drew.adams@oracle.com Date: Fri, 19 Nov 2021 12:33:32 +0100
> > 
> > > > Why? everybody does that now and that’s strictly more recognizable
> > > > for
> > > > most of people (especially newcomers) nowadays
> > > 
> > > Does that mean you want us to go through all our manuals and the
> > > tutorial, and change C-x and C-M-y into Ctrl+x and Ctrl+Alt+y?  And
> > > then change all the key-binding APIs to accept the above notation as
> > > well?  Because if we don't do that, there will be two very different
> > > ways of specifying key sequences, and that will confuse newcomers
> > > even
> > > more.
> > 
> > Yes, and as I said it would be even more nice to have a special
> > syntax/
> > command in texinfo to specify keysequences, so they can be
> > programmatically all be changed very easily, in case the user rebinds
> > them, so not only emacs’ C-h is updated, but the info manual as well
> > (and that could be useful as well for any software whose keys can and
> > commonly are rebound)
> 
> Well, you certainly expect others to do a lot of work here.

I don’t expect anything from anyone.  That’s a lot of work, and volunteers 
cannot be considered responsible for keeping the status quo because that 
involves (gratis) work (+ maintainance goes before the rest, and it’s 
already voluntary work).

What you already do of course is already amazing :)

Anyway initially I was just suggesting to merely *allow* for a + to 
replace a -, for the future, given what’s possible, and what’s done out 
there.

RE: [External] : New key binding syntax

[Drew Adams]

rs> > > I also wonder if there could be confusion between M-RET
rs> > > and M-<return> if the former can be written M-ret and
rs> > > the latter can me written M-return.
rs> 
rs> da> There's no confusion.  (And the former cannot be
rs> da> written M-ret.)
rs> 
rs> As long as we keep the rule that the special control character
rs> names must be upper case, and  function key names must be
rs> lower-case,I think it will avoid confusion.

Those few exceptions have been baked into Emacs "forever".
If we don't make those particular exceptions then we'll
anyway need some way to disambiguate those named control
keys from arbitrarily named (or predefined) function keys.

We could of course force the use of `C-i' etc., but why
not stick with allowing the names?  (Or alternatively,
names such as CR for RET/C-m, LF for newline/C-j, etc.)
And of course SPC is not a "control char" - and there's
no special abbreviation/name for it (decimal 32).

But discussing this is really, I think, orthogonal to
dropping the need for angle brackets.  It's not the use
of angle brackets that distinguishes <RET> from <ret> or
<TAB> from <tab>.

And we already support dropping angle brackets from those
named ASCII control chars - the brackets are optional:
(kbd "<SPC>") = (kbd "SPC").  (The only exception is TAB,
and that's precisely bug #12535: it should be treated
like the others.)

rs> I think someone proposed to eliminate that rule.

I think you're right.  But I can't keep up with
everything that's been proposed, in this thread and
others, that might affect this.  Likewise, with
everything that might already be happening to Emacs in
this regard.

I responded to your request for ideas/opinions about
maybe having a new key binding syntax.  Almost no one
else answered your call for that.  I suspect the steam
roller is just steaming ahead, regardless of what we
write in this thread.  Might as well write it anyway,
at least for "la petite histoire".

sk> > Of course, if we cared deeply about readability
sk> > we would write instead: Alt + Return

rs> If we stick to that rule, we would want to write `alt'
rs> and `return'.  Allowing spaces inside a single key
rs> name would definitely be confusing as long as space
rs> separates keys in a key sequence.

Our current convention has no such ambiguity; we use
<SPC> or SPC to represent a space char in a key
description.  To me, that's just fine, and it's
important to be able to use space chars to separate
keys of a key sequence, in a key description.

rs> But we could allow `alt-return' as an alternative
rs> to `a-return'.

I don't see any advantage to allowing that.

rs> I see no benefit in allowing `+' as a synonym for `-'.

Nor do I (was that actually proposed somewhere?).

RE: [External] : New key binding syntax

[Drew Adams]

(Thanks for considering this.)

> I agree with your points 1, 2, 4, 5 and 6.
> 
>   > 7. I'm in favor of letting `kbd' and Help descriptions
>   > drop the use of angle brackets altogether.
> 
> I agree that that would be good -- provided no ambiguity results.
> Does anyone see a concrete problem with this?

That's my question too.  As I say, I haven't
run into any problem.  And I've asked for
counter-examples.

The place where we treat things specially is
for the ASCII control keys that have names
(aka abbreviations): NUL, RET, LFD, ESC, SPC,
and DEL.  And, IMO, TAB (see bug #12535).

Other that handling of those names specially
(which we already do in `edmacro-parse-keys',
and which is carried over into the no-angles
case by naked.el), I think there is nothing
special.  `foobar' is handled just as is
`<foobar>', and there can't be any problem.

[We could even look into the possibility of
"function" key names that include more chars
than what we accept now.  That might require
some finessing (dunno).  E.g., if we allowed
`<' and `>' then things get interesting (not
in a good way): `<<foo>>', `foo', `<foo>',
`foo>',...]

>   > 3. Personally, I don't feel a need to allow the
>   > argument to `kbd' to be used on its own (e.g., passed
>   > to `define-key" or its replacement), in place of using
>   > (kbd ARG) - let alone feel a need to prescribe that.
> 
> To allow the new syntax in arguments to old functions such as
> `define-key'  would be desirable if it doesn't cause problems.
> But I think it would lead to incompatibilities or conflicts,
> where an argument has one meaning as a key sequence (old style)
> and another as an argument to `kbd', so I think we can't do it.

I agree.  And I don't think anything is gained
by being able to write (define-key "C-f" ...)
instead of (define-key (kbd "C-f") ...).  And
likewise for any replacement/alternative for
`define-key'.  I think it makes a lot of sense
to continue to use an envelope such as (kbd...).

That was my point #3.  It counters suggestions
that we drop `kbd' (or another such name) as an
envelope, and we just use its (string) argument
directly in `define-key' (or whatever replaces
`define-key').

> I suggest defining new functions to replace
> `define-key' and friends, that will take a
> new-style key sequence as argument and will
> NOT accept an old-style key sequence.

What do you mean by new-style and old-style?
Are you talking, as I was above, about the
proposal to get rid of using `kbd' (or other
name), and just using strings: "C-f" instead
of (kbd "C-f")?  Or are you talking about
something else?

>   > \"S o m\" is _not_ a key sequence.  It's not a
>   > "sequence of the keys 'S', 'o' and 'm'".
> 
> I can't make head or tail of that.  Why the
> backslashes before those doublequotes?

Ask Lars.  He's the one who wrote that, in
the doc-string text you cited.  Presumably
those backslashes were just escaping the `"'
chars in the doc string.  But since you kept
them in the doc-string text that you quoted
and asked us to look at, I kept them also.

But my point there was not about that, at
all.  My point was that a key sequence is a
sequence of keys, whereas a notation "S o m"
is a key-sequence _description_.

That's all.  We should be clear about that
distinction, whether (1) talking among
ourselves about what syntax to use/allow or
(2) talking to users in doc strings.
(Please read again what I said about this.)

> With the default Emacs key bindings, S o m is not a valid
> key sequence, because S is not a prefix key.
> But it COULD be a valid key sequence if you defined S
> as a prefix key, then defined S o as a prefix key.

Yes, of course.  Presumably in the case cited
(in Lars's doc string), "S o m" would be a
(description of) a valid key sequence, with
both `S' and `o' being defined as prefix keys.

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> A suggestion:
>
> (kbd-valid-p "<mouse-1>")
> (kbd-valid-p "<Scroll_Lock>")
>
> should return t, and

Good point.  This does make one of the syntax checks either less
effective, or the syntax is ambiguous.  I went with the latter, but I'm
not sure that's the right thing to do here.

The kbd syntax is

"C-M-<return>"

but allowing dashes inside the brackets means that 

"<C-M-return>"

should be parsed as the key named "C-M-return" (which isn't really
possible).

So I just added some special-casing to disallow the "<C-M-return>" form
in kbd-valid-p.  We'll see... 

> (kbd-valid-p "<123>")
>
> should (I think) return nil.  IOW, kbd-valid-p should use:

I'm not sure -- can there be keys named "123"?  I don't know what the
rules are here -- is there an authoritative source for the syntax of
these names somewhere?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]


>> A suggestion:
>>
>> (kbd-valid-p "<mouse-1>")
>> (kbd-valid-p "<Scroll_Lock>")
>>
>> should return t, and
>
> Good point.  This does make one of the syntax checks either less 
> effective, or the syntax is ambiguous.  I went with the latter, but I'm 
> not sure that's the right thing to do here.
>
> The kbd syntax is
>
> "C-M-<return>"
>
> but allowing dashes inside the brackets means that
>
> "<C-M-return>"
>
> should be parsed as the key named "C-M-return" (which isn't really 
> possible).
>
> So I just added some special-casing to disallow the "<C-M-return>" form 
> in kbd-valid-p.  We'll see...
>
>> (kbd-valid-p "<123>")
>>
>> should (I think) return nil.  IOW, kbd-valid-p should use:
>
> I'm not sure -- can there be keys named "123"?  I don't know what the 
> rules are here -- is there an authoritative source for the syntax of 
> these names somewhere?
>

This is no different from "C-M-return" which you disallow.  In theory 
there could be a key or event whose symbolic name is "C-M-return".  In 
theory there could be a key or event whose symbolic name is "123" (or even 
"0", which is different from the key "0").  In theory there could also be 
a key or event whose symbolic name is "ü", IOW, <ü>.

If the point is to introduce a strict syntax, I think it's up to you to 
decide which key and event names are okay from the point of view of Emacs. 
I think the following should be okay:

- contains at least two characters
- starts with an ASCII letter
- is followed by ASCII letters, digits, - or _
- each - must be preceded by at least two letters or digits
- ends with an ASCII letter or digit

Of course this is rather complex to put in a regexp, which is one of the 
reasons I chose to use a C function to do that check.

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> If the point is to introduce a strict syntax, I think it's up to you
> to decide which key and event names are okay from the point of view of
> Emacs.

I imagined that the OS was feeding us the event names somehow (from xkb
in X, for instance), but that's perhaps not true?

In keyboard.c, we have lispy_accent_keys, lispy_multimedia_keys and
lispy_function_keys (etc) that perhaps lists (exhaustively) all the keys
we can handle?

Let's see...  make_lispy_event uses all those...  and then

      /* Handle system-specific or unknown keysyms.
	 We need to use an alist rather than a vector as the cache
	 since we can't make a vector long enough.  */
      if (NILP (KVAR (current_kboard, system_key_syms)))
	kset_system_key_syms (current_kboard, Fcons (Qnil, Qnil));
      return modify_event_symbol (event->code,
				  event->modifiers,
				  Qfunction_key,
				  KVAR (current_kboard, Vsystem_key_alist),
				  0, &KVAR (current_kboard, system_key_syms),
				  PTRDIFF_MAX);

Which...  Uhm, actually, I'm not sure what this returns, since
NAME_ALIST_OR_STEM isn't a stem here.

Anyway, it seems like we (more or less) have a complete list of all
symbols that are possible, but there's no way to ask Emacs "is this a
valid lispy event name?"  And it depends on the OS -- so we can't really
create a function based on the lispy_ C arrays either, because it'd be
annoying to get errors (or warnings) on different systems.

But it does seem true that none of our events start with a number, or a
dash, or an underscore.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]


>
> Anyway, it seems like we (more or less) have a complete list of all 
> symbols that are possible, but there's no way to ask Emacs "is this a 
> valid lispy event name?"  And it depends on the OS -- so we can't really 
> create a function based on the lispy_ C arrays either, because it'd be 
> annoying to get errors (or warnings) on different systems.
>

And as Eli just said, Emacs (or an Emacs package) could invent new 
symbolic names for events at any time.

>
> But it does seem true that none of our events start with a number, or a 
> dash, or an underscore.
>

Indeed.  We were working on this in parallel, so just in case, I attach 
the last version of my patch, which performs I think a more thorough check 
of the key binding string.

BTW, I think something was still unclear in my proposal.  I was not 
suggesting to use, in the long term, strings for both the kbd syntax and 
for strings where every char represents an event.  What I was suggesting 
is to allow both syntaxes for one Emacs release, and to deprecate the 
"strings where every char represents an event" in the next Emacs release 
(or possibly to create a specific notation for them if removing them is 
not possible).  IOW, the long term situation would be unambiguous.  Do you 
really think that it's better, in the long term, to see

(define-key ... ["C-a"] ...)

everywhere (or almost everywhere), instead of

(define-key ... "C-a" ...)

?

[-- Attachment #2: Type: text/x-diff, Size: 7723 bytes --]

From fe57aa57ccc23ecb5387bc321c7564f1a7ee904e Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Mon, 18 Oct 2021 11:45:43 +0000
Subject: [PATCH] Make it possible to use the kbd key binding syntax in more
 places.

* src/keymap.c (Fstring_key_binding_p,
maybe_convert_string_key_binding): New functions.
(Fdefine_key, Flookup_key, Fkey_binding, Fminor_mode_key_binding):
Use the new functions, and document the change.
(syms_of_keymap): Add symbols.
---
 src/keymap.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/src/keymap.c b/src/keymap.c
index 5324f7f021..90efe41827 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1026,6 +1026,113 @@ DEFUN ("copy-keymap", Fcopy_keymap, Scopy_keymap, 1, 1, 0,
 
 /* GC is possible in this function if it autoloads a keymap.  */
 
+DEFUN ("string-key-binding-p", Fstring_key_binding_p, Sstring_key_binding_p,
+       1, 1, 0,
+       doc: /* Whether STRING contains a valid key binding sequence.
+
+A valid key binding sequence is a sequence of valid key bindings separated
+by single spaces.
+A valid key binding starts with a sequence of zero or more modifiers, each
+represented with one of the letters ACMSHs, and each followed by a single
+dash (-), in which no modifier appears more than once, and ends with a
+valid key or a valid event.
+A valid key is either a single visible ASCII or Unicode character, or one
+of the following symbolic characters: NUL (representing the ASCII character
+0 or C-@), TAB (9 or C-i), LFD (10 or C-j), RET (13 or C-m), ESC (27 or C-[),
+SPC (32 or space), DEL (127 or C-?).
+A valid event is a sequence of two or more characters enclosed by angle
+brackets (<>), which can only contain ASCII letters and digits, dashes (-)
+and underscores (_), which must start with a letter, which must end with a
+letter or a digit, and in which the first dash cannot appear before the
+second character.
+If STRING is not a string, returns nil.  */)
+  (Lisp_Object string)
+{
+  bool mod[6];
+  bool space = false;
+  int chars, bytes;
+  char *key;
+
+  if (!STRINGP (string))
+    return Qnil;
+
+  key = SSDATA (string);
+  if (strlen (key) == 0)
+    return Qnil;
+
+  while (*key)
+    if (*key == ' ' || space)
+      {
+        if (*key == ' ' && !*(key + 1))
+          return Qnil;
+        if ((*key == ' ') ^ space)
+          return Qnil;
+        space = false;
+        key++;
+      }
+    else
+      {
+        space = true;
+        mod[0] = mod[1] = mod[2] = mod[3] = mod[4] = mod[5] = false;
+        while (((*key == 'A' && !mod[0] && (mod[0] = true)) ||
+                (*key == 'C' && !mod[1] && (mod[1] = true)) ||
+                (*key == 'H' && !mod[2] && (mod[2] = true)) ||
+                (*key == 'M' && !mod[3] && (mod[3] = true)) ||
+                (*key == 's' && !mod[4] && (mod[4] = true)) ||
+                (*key == 'S' && !mod[5] && (mod[5] = true))) &&
+               *(key + 1) == '-')
+          key += 2;
+        if (*key == '<' &&
+            ((*(key + 1) >= 'a' && *(key + 1) <= 'z') ||
+             (*(key + 1) >= 'A' && *(key + 1) <= 'Z')))
+          {
+            key++;
+            chars = 0;
+            while (*key && *key != '>')
+              if ((*key >= 'a' && *key <= 'z') ||
+                  (*key >= 'A' && *key <= 'Z') ||
+                  (*key >= '0' && *key <= '9') ||
+                  (*key == '-' && chars > 1 && *(key + 1) != '>') ||
+                  (*key == '_' && *(key + 1) != '>'))
+                chars++, key++;
+              else
+                return Qnil;
+            if ((*key != '>') || (*key == '>' && chars < 2))
+              return Qnil;
+            key++;
+          }
+        else if (!strncmp (key, "NUL", 3) || !strncmp (key, "RET", 3) ||
+                 !strncmp (key, "LFD", 3) || !strncmp (key, "TAB", 3) ||
+                 !strncmp (key, "ESC", 3) || !strncmp (key, "SPC", 3) ||
+                 !strncmp (key, "DEL", 3))
+          key += 3;
+        else if (*key >= '!' && *key <= '~')
+          key++;
+        else if (STRING_MULTIBYTE (string) && LEADING_CODE_P (*key))
+          {
+            bytes = BYTES_BY_CHAR_HEAD (*key++) - 1;
+            while (bytes && *key && TRAILING_CODE_P (*key))
+              bytes--, key++;
+            if (bytes)
+              return Qnil;
+          }
+        else
+          return Qnil;
+      }
+  return Qt;
+}
+
+static Lisp_Object
+maybe_convert_string_key_binding (Lisp_Object key)
+{
+  Lisp_Object string_key_binding;
+  if (!NILP (Fstring_key_binding_p (key)) &&
+      !NILP (Ffboundp (Qkbd)) &&
+      !NILP ((string_key_binding = safe_call1 (Qkbd, key))))
+    key = string_key_binding;
+  return key;
+}
+
 DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
        doc: /* In KEYMAP, define key sequence KEY as DEF.
 KEYMAP is a keymap.
@@ -1037,6 +1144,10 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
  [remap COMMAND] remaps any key binding for COMMAND.
  [t] creates a default definition, which applies to any event with no
     other definition in KEYMAP.
+When KEY is in the format of the `string-key-binding-p' predicate,
+it is first processed by `kbd', which see.  Note: in Emacs 30, a warning
+will be displayed for strings returning nil with `string-key-binding-p';
+in Emacs 31, they will raise an error.
 
 DEF is anything that can be a key's definition:
  nil (means key is undefined in this keymap),
@@ -1061,6 +1172,8 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
 {
   bool metized = false;
 
+  key = maybe_convert_string_key_binding (key);
+
   keymap = get_keymap (keymap, 1, 1);
 
   ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
@@ -1206,6 +1319,8 @@ DEFUN ("lookup-key", Flookup_key, Slookup_key, 2, 3, 0,
 {
   bool t_ok = !NILP (accept_default);
 
+  key = maybe_convert_string_key_binding (key);
+
   if (!CONSP (keymap) && !NILP (keymap))
     keymap = get_keymap (keymap, true, true);
 
@@ -1579,6 +1694,10 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 DEFUN ("key-binding", Fkey_binding, Skey_binding, 1, 4, 0,
        doc: /* Return the binding for command KEY in current keymaps.
 KEY is a string or vector, a sequence of keystrokes.
+When KEY is in the format of the `string-key-binding-p' predicate,
+it is first processed by `kbd', which see.  Note: in Emacs 30, a warning
+will be displayed for strings returning nil with `string-key-binding-p';
+in Emacs 31, they will raise an error.
 The binding is probably a symbol with a function definition.
 
 Normally, `key-binding' ignores bindings for t, which act as default
@@ -1604,6 +1723,8 @@ DEFUN ("key-binding", Fkey_binding, Skey_binding, 1, 4, 0,
   */)
   (Lisp_Object key, Lisp_Object accept_default, Lisp_Object no_remap, Lisp_Object position)
 {
+  key = maybe_convert_string_key_binding (key);
+
   if (NILP (position) && VECTORP (key))
     {
       if (ASIZE (key) == 0)
@@ -1663,6 +1784,8 @@ DEFUN ("minor-mode-key-binding", Fminor_mode_key_binding, Sminor_mode_key_bindin
   int nmaps = current_minor_maps (&modes, &maps);
   Lisp_Object binding = Qnil;
 
+  key = maybe_convert_string_key_binding (key);
+
   int j;
   for (int i = j = 0; i < nmaps; i++)
     if (!NILP (maps[i])
@@ -3263,4 +3386,7 @@ syms_of_keymap (void)
   defsubr (&Stext_char_description);
   defsubr (&Swhere_is_internal);
   defsubr (&Sdescribe_buffer_bindings);
+  defsubr (&Sstring_key_binding_p);
+
+  DEFSYM (Qkbd, "kbd");
 }
-- 
2.33.0

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> What I was suggesting is to allow both syntaxes for one Emacs release,
> and to deprecate the "strings where every char represents an event" in
> the next Emacs release (or possibly to create a specific notation for
> them if removing them is not possible).

Removing or changing the current string-based syntax would be
impossible, so a plan that starts with as a criterion is already dead.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Gregory Heytings]

>> What I was suggesting is to allow both syntaxes for one Emacs release, 
>> and to deprecate the "strings where every char represents an event" in 
>> the next Emacs release (or possibly to create a specific notation for 
>> them if removing them is not possible).
>
> Removing or changing the current string-based syntax would be 
> impossible, so a plan that starts with as a criterion is already dead.
>

Hence the "create a specific notation for them if removing them is not 
possible".  E.g. use a "{string}" syntax in the (rare) cases where the 
current string-based syntax is necessary, and use the "string" syntax in 
all other cases.

Re: Moving kbd to subr.el

[Stefan Monnier]

> Hence the "create a specific notation for them if removing them is not
> possible".  E.g. use a "{string}" syntax in the (rare) cases where the
> current string-based syntax is necessary, and use the "string" syntax in all
> other cases.

If you have the liberty to change the string, then you can always (or
close enough) use the kbd syntax.

The reason to preserve the old syntax is to support old code that nobody
will/can update.


        Stefan

Re: Moving kbd to subr.el

[Gregory Heytings]

>> Hence the "create a specific notation for them if removing them is not 
>> possible".  E.g. use a "{string}" syntax in the (rare) cases where the 
>> current string-based syntax is necessary, and use the "string" syntax 
>> in all other cases.
>
> If you have the liberty to change the string, then you can always (or 
> close enough) use the kbd syntax.
>
> The reason to preserve the old syntax is to support old code that nobody 
> will/can update.
>

I understand this, although I'm not sure what "nobody can update" means. 
After all, changing a few characters here and there is not an infeasible 
task.  It's also why I wasn't suggesting to deprecate them in a near 
future, but progressively.  The warning in Emacs 29+N could even mention 
what the replacement string should be, something like: "Warning 
(define-key): "\C-ca" uses a deprecated syntax, it should be replaced by 
"C-c a"."

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Removing or changing the current string-based syntax would be
> impossible, so a plan that starts with as a criterion is already dead.

Can't we impose pretty much any syntax we like in new forms, such as
'defvar-keymap' and 'kbd-valid-p'?

I'm looking at a fragment like this:

   "P"         #'cvs-status-prev
-  (kbd "M-n") #'cvs-status-next
-  (kbd "M-p") #'cvs-status-prev
+  ["M-n"]     #'cvs-status-next
+  ["M-p"]     #'cvs-status-prev
   "t"         #'cvs-status-cvstrees

And I feel like it would be nice if we could avoid putting these
strings in a vector.  Especially if we don't do it consistently.

At the same time, maybe I don't understand the overreaching plan.  Is
the idea to be able to replace any use of (kbd "M-x") with ["M-x"]
everywhere, including in 'define-key' et al?

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> At the same time, maybe I don't understand the overreaching plan.  Is
> the idea to be able to replace any use of (kbd "M-x") with ["M-x"]
> everywhere, including in 'define-key' et al?

Yes.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> > At the same time, maybe I don't understand the overreaching plan.  Is
> > the idea to be able to replace any use of (kbd "M-x") with ["M-x"]
> > everywhere, including in 'define-key' et al?
> 
> Yes.

Could you please remind us clearly why (a
summary)?

The person who started this thread (and with a
patch) now says he doesn't understand the plan.
That likely goes double for some others of us.

What's the aim?  What's wrong with (kbd ...)?
Is there a real problem in view, that this
plan aims to solve?

This long thread started with the Subject:
"Moving `kbd' to subr.el", with the proviso
"If this is something we want to do".  Where
are we/you now?

Re: [External] : Re: Moving kbd to subr.el

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> The person who started this thread (and with a
> patch) now says he doesn't understand the plan.

I don't think I understand how me asking for a clarification could be
interpreted as an argument against these improvements.

The patch to make kbd usable in pre-loaded code really has very little
to do with this, BTW.

> What's the aim?  What's wrong with (kbd ...)?

We have discussed the problems with 'kbd' in some detail in this thread.

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> > The person who started this thread (and with a
> > patch) now says he doesn't understand the plan.
> 
> I don't think I understand how me asking for a
> clarification could be interpreted as an argument
> against these improvements.

I don't see how anyone could take what I said there
as interpreting your request for clarification that
way.  I don't interpret it that way.  What I said
just repeats what you said:

  maybe I don't understand the overreaching plan.
  Is the idea...?

Do you feel I misrepresented what you said?  That
wasn't my intention, at least.  And I quoted you.

If you were asking that at this point, it occurred
to me that I might not be the only person who'd
appreciate a summary.

> > What's the aim?  What's wrong with (kbd ...)?
> 
> We have discussed the problems with 'kbd' in
> some detail in this thread.

I'm sure you have.  It's a long thread.  I asked
for a summary.  Is that asking too much?  Seems
like that should be simple to provide.  If not,
or if no one wants to provide it, fine.

Re: Moving kbd to subr.el

[Stefan Monnier]

> I'm looking at a fragment like this:
>
>    "P"         #'cvs-status-prev
> -  (kbd "M-n") #'cvs-status-next
> -  (kbd "M-p") #'cvs-status-prev
> +  ["M-n"]     #'cvs-status-next
> +  ["M-p"]     #'cvs-status-prev
>    "t"         #'cvs-status-cvstrees

Indeed, it seems if the plan is to promote the `kbd` syntax (which
seems to be what we're doing, both by making `kbd` usable in preloaded
code, or by adding the ["..."] alternative syntax for it), then it makes
sense for `define-keymap` to interpret all strings as `kbd` syntax
(i.e. not support the old string syntax at all).


        Stefan

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed, it seems if the plan is to promote the `kbd` syntax (which
> seems to be what we're doing, both by making `kbd` usable in preloaded
> code, or by adding the ["..."] alternative syntax for it), then it makes
> sense for `define-keymap` to interpret all strings as `kbd` syntax
> (i.e. not support the old string syntax at all).

We could indeed, but I don't want to have different syntaxes in
different functions.  It'd suck if you can't lift a key definition from
`define-keymap' and use it in `local-set-key'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Monnier]

Lars Ingebrigtsen [2021-10-18 17:58:23] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Indeed, it seems if the plan is to promote the `kbd` syntax (which
>> seems to be what we're doing, both by making `kbd` usable in preloaded
>> code, or by adding the ["..."] alternative syntax for it), then it makes
>> sense for `define-keymap` to interpret all strings as `kbd` syntax
>> (i.e. not support the old string syntax at all).
> We could indeed, but I don't want to have different syntaxes in
> different functions.  It'd suck if you can't lift a key definition from
> `define-keymap' and use it in `local-set-key'.

Then I suggest not to support strings at all in `define-keymap`.
The old string syntax for keys just sucks and we should work towards
its reduction, even if it will stay with us for the foreseeable future.

        Stefan

Re: Moving kbd to subr.el

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Then I suggest not to support strings at all in `define-keymap`.
> The old string syntax for keys just sucks and we should work towards
> its reduction, even if it will stay with us for the foreseeable future.

Would it make sense to document the old string syntax (e.g. "\C-xa") to
be "considered deprecated" or something to that effect?

Re: Moving kbd to subr.el

[Stefan Monnier]

Stefan Kangas [2021-10-18 13:40:19] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Then I suggest not to support strings at all in `define-keymap`.
>> The old string syntax for keys just sucks and we should work towards
>> its reduction, even if it will stay with us for the foreseeable future.
> Would it make sense to document the old string syntax (e.g. "\C-xa") to
> be "considered deprecated" or something to that effect?

That would be my preference, yes,


        Stefan

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 18 Oct 2021 13:40:19 -0700
> Cc: Gregory Heytings <gregory@heytings.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Then I suggest not to support strings at all in `define-keymap`.
> > The old string syntax for keys just sucks and we should work towards
> > its reduction, even if it will stay with us for the foreseeable future.
> 
> Would it make sense to document the old string syntax (e.g. "\C-xa") to
> be "considered deprecated" or something to that effect?

"Considered": yes.  But let's not cause it produce warnings when
byte-compiling etc.

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> We could indeed, but I don't want to have different syntaxes in
>> different functions.  It'd suck if you can't lift a key definition from
>> `define-keymap' and use it in `local-set-key'.
>
> Then I suggest not to support strings at all in `define-keymap`.

The same argument is as valid in the opposite direction.  I.e., if you
see a key binding used in `local-set-key', you should be able to use it
in `define-keymap'.

> The old string syntax for keys just sucks and we should work towards
> its reduction, even if it will stay with us for the foreseeable future.

I totally agree that the old string syntax for keys sucks, but there is
no realistic way to phase it out.  `kbd' was a nice attempt, but it's
not attractive enough as is.  My hope is that the new syntax (which
gives you actual error messages if you do something wrong and stuff)
will spur conversion.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Juri Linkov]

>> The old string syntax for keys just sucks and we should work towards
>> its reduction, even if it will stay with us for the foreseeable future.
>
> I totally agree that the old string syntax for keys sucks, but there is
> no realistic way to phase it out.  `kbd' was a nice attempt, but it's
> not attractive enough as is.  My hope is that the new syntax (which
> gives you actual error messages if you do something wrong and stuff)
> will spur conversion.

The first step to phase the old syntax out would be to use the new syntax
in define-keymap and defvar-keymap by default.

This is nicer:

   "P"         #'cvs-status-prev
   "M-n"       #'cvs-status-next
   "M-p"       #'cvs-status-prev
   "t"         #'cvs-status-cvstrees

than this:

   :kbd nil
   "P"         #'cvs-status-prev
   ["M-n"]     #'cvs-status-next
   ["M-p"]     #'cvs-status-prev
   "t"         #'cvs-status-cvstrees

Re: Moving kbd to subr.el

[Gregory Heytings]

>> The old string syntax for keys just sucks and we should work towards 
>> its reduction, even if it will stay with us for the foreseeable future.
>
> I totally agree that the old string syntax for keys sucks, but there is 
> no realistic way to phase it out.  `kbd' was a nice attempt, but it's 
> not attractive enough as is.  My hope is that the new syntax (which 
> gives you actual error messages if you do something wrong and stuff) 
> will spur conversion.
>

I'm puzzled.  There is a way to phase it out, in fact this was one of the 
(two) explict goals of my proposal, and it was also the reason why you 
rejected it.  What am I misunderstanding?

This thread is rather long, so for those who did not read all its posts, 
this is what my proposal is:

Emacs 29: allow both syntaxes (kbd and old) in strings; these syntaxes are 
different and can be distinguised programmatically (with very few 
exceptions, namely someone who would use e.g. "C-o" to mean "C - o" or "a 
b" to mean "a SPC b").

Emacs 29 + N: allow both syntaxes (kbd and old), but display a warning 
when the old syntax is used (mentioning what the new syntax should be), 
and possibly (if for some reason the old syntax is necessary in some 
cases) introduce a new specific syntax for it (e.g. "{\C-ca}").

Emacs 29 + 2*N: allow only the kbd syntax, display an error otherwise.

Sure, this could break some configurations and some old code, but not more 
than when the cl- prefix was added to the cl-lib library, or to take a 
more recent (current) example when xref switched from eieio to 
cl-defstruct.  And unlike these examples the fix is in each case as simple 
as possible.

Re: Moving kbd to subr.el

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

> This thread is rather long, so for those who did not read all its
> posts, this is what my proposal is:

I sadly didn't follow the thread from the beginning (because the subject
wasn't changed), but was the actual issue with using kbd discussed
somewhere you could point me to?

-- 
	Philip Kaludercic

Re: Moving kbd to subr.el

[Gregory Heytings]

>> This thread is rather long, so for those who did not read all its 
>> posts, this is what my proposal is:
>
> I sadly didn't follow the thread from the beginning (because the subject 
> wasn't changed), but was the actual issue with using kbd discussed 
> somewhere you could point me to?
>

I don't think there was a discussion about an "actual issue", it was 
observed that (1) the old string key binding format "sucks", and (2) 
requiring to wrap each key binding written in the "modern" string key 
binding format (the one that's used everywhere) in an explicit call to kbd 
is inconvenient.

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> I sadly didn't follow the thread from the beginning
> (because the subject wasn't changed), but was the
> actual issue with using kbd discussed somewhere you
> could point me to?

+1.

I asked yesterday, and was summarily rebuked, and
the request ignored.  Hope you have better luck.

https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01343.html

RE: [External] : Re: Moving kbd to subr.el

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

>> I sadly didn't follow the thread from the beginning
>> (because the subject wasn't changed), but was the
>> actual issue with using kbd discussed somewhere you
>> could point me to?
>
> +1.
>
> I asked yesterday, and was summarily rebuked, and
> the request ignored.  Hope you have better luck.

IMHO, "summarily rebuked" is a overstating the case.

As I explained in my reply to you yesterday, this is all in the
archives.  Here is one possible starting point:

    https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01098.html

If you want to dig even deeper, see the test-cases in subr-tests.el, and
the rest of this thread.

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> this is all in the archives.

I'm sure it is.  The request was for a _summary_
of the problem and why we would want to "replace
any use of" kbd, which was presented as the
"overarching plan".

> Here is one possible starting point:
> https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01098.html

Thanks.  But what part of "summary" was unclear?
A pointer to the archives isn't what I had in mind.

> If you want to dig even deeper, see the test-cases
> in subr-tests.el, and the rest of this thread.

I asked for a summary, not a pointer to piles to
search through.
___

If your "starting point" is intended as a summary
of why we need to replace kbd then FWIW I'm not
convinced.

`kbd' accepts as input what Emacs itself writes
as help descriptions of key sequences.

Wrt your "starting point":

* _Emacs_ doesn't write "f 1" for what you apparently
  expect/want.  It writes "f <SPC> 1" for that.
  And kbd correctly returns "f 1" for that, as that
  return value can be used to bind a key.

* _Emacs_ doesn't write "f1" for what you apparently
  expect/want.  It writes "<f1>".  And kbd correctly
  returns [f1].

* _Emacs_ doesn't write "return" for what...  It
  writes "<return>".  And kbd returns [return].

It's about how _Emacs_ itself talks to users about
keys - the names/descriptions it gives them in its
Help. Users of `kbd' can talk to Emacs in the same
terms that Emacs talks to them about keys.

`kbd' expects as input a description such as Emacs
itself uses in its help output.  If you pass `kbd'
text that Emacs does NOT use as a key description
then all bets are off.

But if you find some _legitimate_ key description
(i.e., syntax that Emacs itself uses) that `kbd'
mishandles, maybe file a bug report for that?

Perhaps `kbd' should raise an error if its input
is _not_ a legitimate Emacs key description?
Would that have helped you avoid listing such
expressions as being problems with `kbd', i.e.,
reasons to replace `kbd'?
___

As for replacing syntax "\C-a" with "C-a", outside
of any use of `kbd': that's a different question,
I think.

That question doesn't seem to fit either your
"starting point" or Lars's confirmation that the
"overarching plan" is to replace `kbd'.

There seems to be more "arching" going on in this
thread than is contained in the "overarching plan".

I'd still like to see a clear summary of what are
thought to be the problems to solve, and what are
the proposed solutions.  (Again, "summary", not
pointers to a discussion wall.)

RE: [External] : Re: Moving kbd to subr.el

[Drew Adams]

> * _Emacs_ doesn't write "return" for what...  It
>   writes "<return>".  And kbd returns [return].
> 
> It's about how _Emacs_ itself talks to users about
> keys - the names/descriptions it gives them in its
> Help. Users of `kbd' can talk to Emacs in the same
> terms that Emacs talks to them about keys.

BTW (related, but maybe OT, depending on how
"free-range" this thread really is):

It's entirely possible to do without the use of
angle brackets in Emacs key descriptions.  I've
mentioned this before (more than once, likely).

I do that in my library `naked.el'.  Function
`naked' is `kbd', with the option of not bothering
with angle brackets.  More precisely, by default
it expects not angle brackets, but with an optional
arg it behaves exactly like `kbd'.

`naked' doc string:

 Like `kbd', but does not use angle brackets, by default.
 With non-nil optional arg ANGLES, expect key descriptions
 to use angle brackets (<...>), exactly like `kbd'.
 Otherwise, expect key descriptions not to use angle brackets.
 For example:

  (naked "mode-line")     returns [mode-line]
  (naked "<mode-line>" t) returns [mode-line]

 The default behavior lets you use, e.g., "C-x delete" and
 "C-delete" instead of "C-x <delete>" and "C-<delete>".
___

https://www.emacswiki.org/emacs/NaKeD

https://www.emacswiki.org/emacs/download/naked.el

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Emacs 29 + 2*N: allow only the kbd syntax, display an error otherwise.

Indeed, you have demonstrated it would be _possible_ to eliminate the
old key binding syntax.

But we _should not do that_.  The breakage of so many old programs
would be terribly harmful, and there is no need for it at all.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Emacs 29 + 2*N: allow only the kbd syntax, display an error otherwise.

Indeed, you have demonstrated it would be _possible_ to eliminate the
old key binding syntax.

But we _should not do that_.  The breakage of so many old programs
would be gratuitous harm and pain!

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

  >   Whether we do manage to completely remove it or not
  > doesn't matter very much for the benefit of Emacs users we should make
  > it so the user and coder will never need to know about it, and for that
  > we should actively discourage its use

That I'm in favor of.

                                         , starting by not supporting it
  > where it doesn't have to be supported.

That's so terse and abstract that I am not sure what it concretely
means.  Maybe it's a good idea.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Emacs 29 + 2*N: allow only the kbd syntax, display an error otherwise.

> Sure, this could break some configurations and some old code

Almost all my code uses the old syntax.  And I'm sure a lot of other
code too, not necessarily old.

It might be ugly, but there's no harm in leaving it there, and a great
deal of harm in removing it.

As for the comparisons with xref and cl-lib, they're not accurate at
all.  Code using old cl will still work thanks to the compatibility
shims, and almost nobody uses xref anyway.

Just my two cents.  Thanks.

Re: Moving kbd to subr.el

[Stefan Monnier]

Lars Ingebrigtsen [2021-10-19 04:30:38] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> We could indeed, but I don't want to have different syntaxes in
>>> different functions.  It'd suck if you can't lift a key definition from
>>> `define-keymap' and use it in `local-set-key'.
>> Then I suggest not to support strings at all in `define-keymap`.
> The same argument is as valid in the opposite direction.  I.e., if you
> see a key binding used in `local-set-key', you should be able to use it
> in `define-keymap'.

I don't think this holds.
It's normal for higher-level APIs to rely on higher-level representations.

>> The old string syntax for keys just sucks and we should work towards
>> its reduction, even if it will stay with us for the foreseeable future.
> I totally agree that the old string syntax for keys sucks, but there is
> no realistic way to phase it out.

In the short term, no, but if you look at the 10-20 year horizon it
seems quite doable.  Whether we do manage to completely remove it or not
doesn't matter very much for the benefit of Emacs users we should make
it so the user and coder will never need to know about it, and for that
we should actively discourage its use, starting by not supporting it
where it doesn't have to be supported.


        Stefan

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't think this holds.
> It's normal for higher-level APIs to rely on higher-level representations.

That's true...  but `define-keymap' and `define-key' are pretty much on
the same level.  I.e., both are public Emacs Lisp functions that define
keys.

> In the short term, no, but if you look at the 10-20 year horizon it
> seems quite doable.  Whether we do manage to completely remove it or not
> doesn't matter very much for the benefit of Emacs users we should make
> it so the user and coder will never need to know about it, and for that
> we should actively discourage its use, starting by not supporting it
> where it doesn't have to be supported.

Is it worth 20 years of pain?

I think Stefan K suggested making a whole new set of all these functions
that would only understand the new syntax.  I didn't think that would be
doable, because there's so many of them, but I didn't actually count.
Let's see...

define-keymap
define-key
global-set-key
global-unset-key
local-set-key
local-unset-key
lookup-key

OK, that's fewer than I thought.  So, new random thought:

kbd-keymap
kbd-define
kbd-set-globally
kbd-unset-globally
kbd-set-locally
kbd-unset-locally
kbd-lookup

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> OK, that's fewer than I thought.  So, new random thought:
>
> kbd-keymap
> kbd-define
> kbd-set-globally
> kbd-unset-globally
> kbd-set-locally
> kbd-unset-locally
> kbd-lookup

I like it.  (I was experimenting with a prefix "defkey" but couldn't
come up with a nice set of names like the set you have above.)

AFAICT, this approach has one important advantage that none of the
others have: it frees us from most of the legacy stuff in one go,
while still allowing us to leave the legacy interface as-is.

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> OK, that's fewer than I thought.  So, new random thought:
>>
>> kbd-keymap
>> kbd-define

That's perhaps confusing.  Perhaps

define-kbdmap
define-kbd

but I guess there's something attractive about having them all with the
same prefix...

Er...

kdb-define-keymap
kbd-define-key

Hm...

>> kbd-set-globally
>> kbd-unset-globally
>> kbd-set-locally
>> kbd-unset-locally
>> kbd-lookup

[...]

> AFAICT, this approach has one important advantage that none of the
> others have: it frees us from most of the legacy stuff in one go,
> while still allowing us to leave the legacy interface as-is.

Yup.  And having "kbd" in the name should make it all less confusing,
perhaps, and we could (eventually) use the normal deprecation procedures
for the old functions.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yup.  And having "kbd" in the name should make it all less confusing,
> perhaps, and we could (eventually) use the normal deprecation procedures
> for the old functions.

Right, we could use "kbd" or perhaps "key".  Whichever we choose, I
would strongly prefer having one shared prefix for all of these
functions.

This simple change reduces cognitive load by quite a bit IMO, as I
just need to remember to type "kbd-" to get the company completion
popup that shows the full names.

> kdb-define-keymap
> kbd-define-key

Maybe:

kbd-define
kbd-define-map

Or, if we use "key" as the prefix:

key-define
key-define-map

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Maybe:
>
> kbd-define
> kbd-define-map

Yeah, that's nice.

> Or, if we use "key" as the prefix:
>
> key-define
> key-define-map

Hm...  "key" would also work.  It's perhaps more ambiguous, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  "key" would also work.  It's perhaps more ambiguous, though.

What ambiguity do you see?  I end up with something like this:

> key-define-map
> key-define
> key-global-set
> key-global-unset
> key-local-set
> key-local-unset
> key-lookup

(Note that I prefer "global/local" before "set/unset", but the other
way around is fine too.)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Hm...  "key" would also work.  It's perhaps more ambiguous, though.
>
> What ambiguity do you see?  I end up with something like this:
>
>> key-define-map
>> key-define
>> key-global-set
>> key-global-unset
>> key-local-set
>> key-local-unset
>> key-lookup

The ambiguity is that if you're reading code with define-key and/or
key-define, the function names don't give you a hint about how they
differ.

> (Note that I prefer "global/local" before "set/unset", but the other
> way around is fine too.)

Yeah, -global-set/-global-unset looks good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Robert Pluim]

>>>>> On Tue, 19 Oct 2021 16:25:30 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> Hm...  "key" would also work.  It's perhaps more ambiguous, though.

    Stefan> What ambiguity do you see?  I end up with something like this:

    >> key-define-map
    >> key-define
    >> key-global-set
    >> key-global-unset
    >> key-local-set
    >> key-local-unset
    >> key-lookup

Having 'key' as a prefix might induce people to believe that weʼre
talking about "defining keys", when what weʼre talking about is "key
bindings"

    Stefan> (Note that I prefer "global/local" before "set/unset", but the other
    Stefan> way around is fine too.)

Hey, this is what completion frameworks are for :-)

Robert
-- 

Re: Moving kbd to subr.el

[Andreas Schwab]

On Okt 19 2021, Lars Ingebrigtsen wrote:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Maybe:
>>
>> kbd-define
>> kbd-define-map
>
> Yeah, that's nice.
>
>> Or, if we use "key" as the prefix:
>>
>> key-define
>> key-define-map
>
> Hm...  "key" would also work.  It's perhaps more ambiguous, though.

This is about keymaps, so the prefix should be keymap.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Moving kbd to subr.el

[Stefan Monnier]

> kbd-define
> kbd-define-map

Since we're in the bikeshedding part of this, let me throw some ideas:

- The name `define-key` might be tolerable because it "defines" the behavior of
  a given key, but I find it shouldn't say "define" but rather something
  like "set" or "put" since it behaves much more like `setq`, `aset`,
  `put`, `puthash`, ...

- I really don't like `define-keymap` because "define" usually gives
  a definition to a name, but here there's no name.  I'd prefer
  something that says "make" or "create", or even just `keymap` (in the
  tradition of reusing a type/class name as the name of the function
  that constructs objects of this type).


        Stefan

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> kbd-define
>> kbd-define-map
>
> Since we're in the bikeshedding part of this, let me throw some ideas:
>
> - The name `define-key` might be tolerable because it "defines" the behavior of
>   a given key, but I find it shouldn't say "define" but rather something
>   like "set" or "put" since it behaves much more like `setq`, `aset`,
>   `put`, `puthash`, ...

That's a really good point.  So `kbd-set'?

> - I really don't like `define-keymap` because "define" usually gives
>   a definition to a name, but here there's no name.  I'd prefer
>   something that says "make" or "create", or even just `keymap` (in the
>   tradition of reusing a type/class name as the name of the function
>   that constructs objects of this type).

I went with "define" since `make-keymap' was taken.  But if we're
switching stuff around, then perhaps...  `kbd-make'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I went with "define" since `make-keymap' was taken.  But if we're
> switching stuff around, then perhaps...  `kbd-make'?

OK, then our current "best of" list looks like:

kbd-make
defvar-kbd
kbd-set
kbd-global-set
kbd-global-unset
kbd-local-set
kbd-local-unset
kbd-lookup

Alternatively:

kbd-make-map
defvar-kbd-map

Hm...  the -map-less ones are perhaps less awkward.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Howard Melman]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> kbd-define
>> kbd-define-map
>
> Since we're in the bikeshedding part of this...

How about a prefix of bike- for bikeshed... um BInd-KEy...

-- 

Howard

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 985 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

how about bind-key instead of define-key --- that "bind" says more
closely what it does.
>> kbd-define
>> kbd-define-map
>
> Since we're in the bikeshedding part of this, let me throw some ideas:
>
> - The name `define-key` might be tolerable because it "defines" the behavior of
>   a given key, but I find it shouldn't say "define" but rather something
>   like "set" or "put" since it behaves much more like `setq`, `aset`,
>   `put`, `puthash`, ...
>
> - I really don't like `define-keymap` because "define" usually gives
>   a definition to a name, but here there's no name.  I'd prefer
>   something that says "make" or "create", or even just `keymap` (in the
>   tradition of reusing a type/class name as the name of the function
>   that constructs objects of this type).
>
>
>         Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

"T.V Raman" <raman@google.com> writes:

> how about bind-key instead of define-key --- that "bind" says more
> closely what it does.

Yeah, I like "bind".  'kbd-bind', perhaps?

Then the other functions would be

kbd-global-bind
kbd-global-unbind

etc?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Dmitry Gutov]

On 19.10.2021 23:59, Lars Ingebrigtsen wrote:
> Yeah, I like "bind".  'kbd-bind', perhaps?
> 
> Then the other functions would be
> 
> kbd-global-bind
> kbd-global-unbind
> 
> etc?

Sounds like a good option.

Re: Moving kbd to subr.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Yeah, I like "bind".  'kbd-bind', perhaps?
  > > 
  > > Then the other functions would be
  > > 
  > > kbd-global-bind
  > > kbd-global-unbind

If we call them `key-bind' and so on, that would be more correct
semantically (as has been pointed out), and we can use whatever format
we like for the key to bind (since these names are new anyway).

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> If we call them `key-bind' and so on, that would be more correct
> semantically (as has been pointed out), and we can use whatever format
> we like for the key to bind (since these names are new anyway).

But the format we want to support is the subset of `kbd' that
`kbd-valid-p' accepts.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 542 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:


works for me.

kbd-bind is better because bind is likely already used by existing
external packages
> "T.V Raman" <raman@google.com> writes:
>
>> how about bind-key instead of define-key --- that "bind" says more
>> closely what it does.
>
> Yeah, I like "bind".  'kbd-bind', perhaps?
>
> Then the other functions would be
>
> kbd-global-bind
> kbd-global-unbind
>
> etc?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Dmitry Gutov]

On 19.10.2021 16:38, Lars Ingebrigtsen wrote:
> I think Stefan K suggested making a whole new set of all these functions
> that would only understand the new syntax.  I didn't think that would be
> doable, because there's so many of them, but I didn't actually count.
> Let's see...
> 
> define-keymap
> define-key
> global-set-key
> global-unset-key
> local-set-key
> local-unset-key
> lookup-key
> 
> OK, that's fewer than I thought.  So, new random thought:
> 
> kbd-keymap
> kbd-define
> kbd-set-globally
> kbd-unset-globally
> kbd-set-locally
> kbd-unset-locally
> kbd-lookup

Perhaps one alternative is to warn about "outdated" syntax in the linter 
(which is currently part of the byte-compiler). It won't catch all uses, 
but enough of them to warn the vast majority of users.

Re: Moving kbd to subr.el

[Gregory Heytings]

>> In the short term, no, but if you look at the 10-20 year horizon it 
>> seems quite doable.  Whether we do manage to completely remove it or 
>> not doesn't matter very much for the benefit of Emacs users we should 
>> make it so the user and coder will never need to know about it, and for 
>> that we should actively discourage its use, starting by not supporting 
>> it where it doesn't have to be supported.
>
> Is it worth 20 years of pain?
>

Which pain?  With my proposal and N=2, this is exactly what would happen, 
in a pretty much painless way.  Unless there's something I misunderstood.

Re: Moving kbd to subr.el

[Gregory Heytings]

>
> I think Stefan K suggested making a whole new set of all these functions 
> that would only understand the new syntax.  I didn't think that would be 
> doable, because there's so many of them, but I didn't actually count.
>

It's not only the number of functions that counts, it's the number of 
times they are used.  define-key only is used ~15000 times in core and 
ELPA.

>
> So, new random thought:
>
> kbd-keymap
> kbd-define
> kbd-set-globally
> kbd-unset-globally 
> kbd-set-locally
> kbd-unset-locally
> kbd-lookup
>

As I already said earlier, that's unreasonable.  It's clear that at some 
point the old functions will be deprecated, so in the end it puts the 
burden on all users and package authors to change their code at many 
places.  When it is possible to ask instead a few users and package 
authors to change a few characters at a few places.

And I bow out of this thread, somehow I feel that my contributions are not 
welcome anymore.

Re: Moving kbd to subr.el

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> It's not only the number of functions that counts, it's the number of
> times they are used.  define-key only is used ~15000 times in core and
> ELPA.

That should give pause when thinking about changing its semantics, IMHO.
Especially now that we seem to be converging on a better alternative.

> As I already said earlier, that's unreasonable.  It's clear that at some
> point the old functions will be deprecated,

I don't see us deprecating the old API any time soon.  For now, I think
that the carrot (a better/cleaner/etc. API) will do more for us than the
stick (e.g. byte-compiler warnings).  But that's me.

> And I bow out of this thread, somehow I feel that my contributions are not
> welcome anymore.

I can only speak for myself, but your contributions here have been
welcome.  As long as we keep it civil and to the point, being met with a
contrary view, even while disagreeing with some of the conclusions, can
force you to sharpen and improve your own arguments and reasoning.
Well-reasoned discussion in that way helps make Emacs better, which
after all is the point of this list.

So I hope that you will continue participating in the discussion and
help us make the new API the best it can be, if that is indeed the
solution that we will finally decide on.

Re: Moving kbd to subr.el

[Juri Linkov]

> Let's see...
>
> define-keymap
> define-key
> global-set-key
> global-unset-key
> local-set-key
> local-unset-key
> lookup-key

Replacing 'key' with 'kbd' in all names will help switching to new syntax,
since there is no need to consult the help and manuals while using
existing functions where only two letters are changed in the name:

define-kbdmap
define-kbd
global-set-kbd
global-unset-kbd
local-set-kbd
local-unset-kbd
lookup-kbd

Making a key undefined again

[Jonas Bernoulli]

> OK, that's fewer than I thought.  So, new random thought:
>
> kbd-keymap
> kbd-define
> kbd-set-globally
> kbd-unset-globally
> kbd-set-locally
> kbd-unset-locally
> kbd-lookup

If we do that, could we please also consider what it means to "unset"
a key.  `local-unset-key' sets a key to nil, but IMO that is not good
enough.

After I have done

  (local-set-key "a" 'a)
  (local-unset-key "a")

I would like the keymap to be in exactly the same state as before I
have done that.

`kmu-remove-key' from my `keymap-utils' package truly removes a key
binding.  Visit or clone from https://github.com/tarsius/keymap-utils.

    (defun kmu-remove-key (keymap key)
      "In KEYMAP, remove key sequence KEY.
    
    Make the event KEY truly undefined in KEYMAP by removing the
    respective element of KEYMAP (or a sub-keymap or a bound prefix
    command) as opposed to merely setting its binding to nil.
    
    There are several ways in which a key can be \"undefined\":
    
       (keymap (65 . undefined) ; A
               (66))            ; B
    
    As far as key lookup is concerned A isn't undefined at all, it is
    bound to the command `undefined' (which doesn't do anything but
    make some noise).  This can be used to override lower-precedence
    keymaps.
    
    B's binding is nil which doesn't constitute a definition but does
    take precedence over a default binding or a binding in the parent
    keymap.  On the other hand, a binding of nil does _not_ override
    lower-precedence keymaps; thus, if the local map gives a binding
    of nil, Emacs uses the binding from the global map.
    
    All other events are truly undefined in KEYMAP.
    
    Note that in a full keymap all characters without modifiers are
    always bound to something, the closest these events can get to
    being undefined is being bound to nil like B above."
      ;; Uses kbd-syntax, but that's not relevant for
      ;; this side-thread, so let's comment that out.
      ;; (when (stringp key)
      ;;   (setq key (kmu-parse-key-description key t)))
      (define-key keymap key nil)
      (setq key (cl-mapcan (lambda (k)
                             (if (and (integerp k)
                                      (/= (logand k ?\M-\0) 0))
                                 (list ?\e (- k ?\M-\0))
                               (list k)))
                           key))
      (if (= (length key) 1)
          (delete key keymap)
        (let* ((prefix (vconcat (butlast key)))
               (submap (lookup-key keymap prefix)))
          (if (not (keymapp submap))
              (error "Cannot remove %; %s is not bound to a keymap" key prefix)
            (when (symbolp submap)
              (setq submap (symbol-function submap)))
            (delete (last key) submap)
            (when (= (length submap) 1)
              (kmu-remove-key keymap prefix))))))

Maybe the code could be simplified; it has been a long time since
I wrote that, with a little help from my friends.  But I hope the
doc-string makes it clear why something like this is desirable.

It would be nice if such a function could be added to Emacs and if
`kbd-unset-{locally,globally}' behaved that way as well.

     Thanks for considering,
     Jonas

RE: [External] : Making a key undefined again

[Drew Adams]

+1 for adding such a function

Re: Making a key undefined again

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@bernoul.li> writes:

> I would like the keymap to be in exactly the same state as before I
> have done that.

Sounds like a good idea to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Making a key undefined again

[Stefan Monnier]

>     (defun kmu-remove-key (keymap key)
[...]
>       (if (= (length key) 1)
>           (delete key keymap)

This means that it can also affect a parent keymap.
In my book this is an absolute no-no: you should never be able to modify
the parent when accessed from a child.

Also, AFAIK the only difference between a nil binding and "no binding at
all" is whether it can hide bindings from the parent, but if you also remove
the binding from the parent, then you end up with the same result as a nil
binding, no?

> Maybe the code could be simplified; it has been a long time since
> I wrote that, with a little help from my friends.  But I hope the
> doc-string makes it clear why something like this is desirable.

Actually, it didn't make it clear for me.  I hope I understand the
differences between an `undefined` binding, a `nil ` binding, and no
binding at all, but I don't know why unsetting a key is important and
even less when unsetting it by making it have no binding at all
is necessary.


        Stefan

Re: Making a key undefined again

[Gregory Heytings]

>
> Actually, it didn't make it clear for me.  I hope I understand the 
> differences between an `undefined` binding, a `nil ` binding, and no 
> binding at all, but I don't know why unsetting a key is important and 
> even less when unsetting it by making it have no binding at all is 
> necessary.
>

I'm not sure I understand what Jonas wants, but here's what I understood:

1. (define-key lisp-interaction-mode-map "\C-j" nil)

means that in *scratch* C-j becomes electric-newline-and-maybe-indent (in 
global-map);

2. (define-key lisp-interaction-mode-map "\C-j" #'undefined)

means that in *scratch* C-j displays "C-j is undefined";

3. (define-key lisp-interaction-mode-map "\C-j" (lambda () (interactive)))

means that in *scratch* C-j does nothing.

Re: Making a key undefined again

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     (defun kmu-remove-key (keymap key)
> [...]
>>       (if (= (length key) 1)
>>           (delete key keymap)

That's a bug (thanks for the report), it should be:

             (cl-delete key keymap :count 1)

There always is a (EVENT) entry in the keymap itself because of this line
further up:

             (define-key keymap key nil)

(At which point KEY still has the form [EVENT], not (EVENT).)

> Also, AFAIK the only difference between a nil binding and "no binding at
> all" is whether it can hide bindings from the parent, but if you also remove
> the binding from the parent, then you end up with the same result as a nil
> binding, no?

This would only have happened (before the bugfix) in a situation like

  (keymap
   (97 . undesired)
   keymap
   (97))

>> Maybe the code could be simplified; it has been a long time since
>> I wrote that, with a little help from my friends.  But I hope the
>> doc-string makes it clear why something like this is desirable.
>
> Actually, it didn't make it clear for me.  I hope I understand the
> differences between an `undefined` binding, a `nil ` binding, and no
> binding at all, but I don't know why unsetting a key is important and
> even less when unsetting it by making it have no binding at all
> is necessary.

Say special-mode `foo-mode' does:

  (define-key foo-mode-map "n" 'foo-next-thing)

And derived mode `foobar-mode' does:

  (set-keymap-parent foobar-mode-map foo-mode-map)
  (define-key foobar-mode-map "n" 'foobar-next-thing-except-if-boring)

But I like plain old `foo-next-thing' better.

If I do

  (define-key foobar-mode-map "n" nil)

then that doesn't bring back `foo-next-thing'.  Instead "n" invokes
`self-insert-command' from `global-map'.

I could do

  (define-key foobar-mode-map "n" 'foo-next-thing)

but that breaks when `foo-next-thing' is renamed to `foo-forward'.
And even if that never happens, it still complicates `foobar-mode-map',
which now has a binding for `foo-next-thing', which isn't actually
necessary because an identical binding exists in the parent keymap
`foo-mode-map'.

     Jonas

Re: Making a key undefined again

[Jonas Bernoulli]

Or rather:

      (cl-delete key keymap :count 1 :test #'equal)

Re: Making a key undefined again

[Stefan Monnier]

>>>     (defun kmu-remove-key (keymap key)
>> [...]
>>>       (if (= (length key) 1)
>>>           (delete key keymap)
>
> That's a bug (thanks for the report), it should be:
>
>              (cl-delete key keymap :count 1)

Ah, I see, that makes more sense.

> There always is a (EVENT) entry in the keymap itself because of this line
> further up:
>
>              (define-key keymap key nil)
>
> (At which point KEY still has the form [EVENT], not (EVENT).)

Actually, it's not guaranteed.  Try it with:

    (let ((parent (make-sparse-keymap))
          (child (make-keymap)))
      (set-keymap-parent child parent)
      (define-key parent [?a] nil)
      (define-key child  [?a] 'bar)
      child)

:-(

>> Actually, it didn't make it clear for me.  I hope I understand the
>> differences between an `undefined` binding, a `nil ` binding, and no
>> binding at all, but I don't know why unsetting a key is important and
>> even less when unsetting it by making it have no binding at all
>> is necessary.
>
> Say special-mode `foo-mode' does:

[ Now that I see the correction to your code, I understand better what
  you mean by "not bound at all".  ]

> but that breaks when `foo-next-thing' is renamed to `foo-forward'.
> And even if that never happens, it still complicates `foobar-mode-map',
> which now has a binding for `foo-next-thing', which isn't actually
> necessary because an identical binding exists in the parent keymap
> `foo-mode-map'.

How common is this case?

So your notion of "no binding at all" can also be described as something
like "use the binding of the parent".


        Stefan

Re: Making a key undefined again

[Gregory Heytings]

>> but that breaks when `foo-next-thing' is renamed to `foo-forward'. And 
>> even if that never happens, it still complicates `foobar-mode-map', 
>> which now has a binding for `foo-next-thing', which isn't actually 
>> necessary because an identical binding exists in the parent keymap 
>> `foo-mode-map'.
>
> How common is this case?
>
> So your notion of "no binding at all" can also be described as something 
> like "use the binding of the parent".
>

This happens because t is stored in the keymap when using (define-key ... 
nil), as explained in store_in_keymap():

Faset (elt, idx,
        /* nil has a special meaning for char-tables, so
 	  we use something else to record an explicitly
 	  unbound entry.  */
        NILP (def) ? Qt : def);

Would it not be possible to add another value that would actually be be 
stored as a nil at that point, for example 'nil / QQnil?

Re: Making a key undefined again

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There always is a (EVENT) entry in the keymap itself because of this line
>> further up:
>>
>>              (define-key keymap key nil)
>>
>> (At which point KEY still has the form [EVENT], not (EVENT).)
>
> Actually, it's not guaranteed.  Try it with:
>
>     (let ((parent (make-sparse-keymap))
>           (child (make-keymap)))
>       (set-keymap-parent child parent)
>       (define-key parent [?a] nil)
>       (define-key child  [?a] 'bar)
>       child)
>
> :-(

That can be fixed too.  How does one determine if an event is / would be
stored in a keymap's char-table?  So far I have:

  (and (char-table-p (cadr MAP))
       (ignore-errors (char-table-range (cadr MAP) EVENT) t))

>> but that breaks when `foo-next-thing' is renamed to `foo-forward'.
>> And even if that never happens, it still complicates `foobar-mode-map',
>> which now has a binding for `foo-next-thing', which isn't actually
>> necessary because an identical binding exists in the parent keymap
>> `foo-mode-map'.
>
> How common is this case?

When implementing an alternative set of key bindings across all of Emacs
that diverge from the "standard Emacs key bindings" a lot (up to the
scale of Vim but possibly not quite *that* drastically different), then
it might be needed for essentially every keymap.

> So your notion of "no binding at all" can also be described as something
> like "use the binding of the parent".

Yes. (Or the default binding, or ...)

remove(add(MAP KEY) KEY) == MAP

Re: Making a key undefined again

[Stefan Monnier]

Jonas Bernoulli [2021-10-26 18:11:53] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> There always is a (EVENT) entry in the keymap itself because of this line
>>> further up:
>>>
>>>              (define-key keymap key nil)
>>>
>>> (At which point KEY still has the form [EVENT], not (EVENT).)
>>
>> Actually, it's not guaranteed.  Try it with:
>>
>>     (let ((parent (make-sparse-keymap))
>>           (child (make-keymap)))
>>       (set-keymap-parent child parent)
>>       (define-key parent [?a] nil)
>>       (define-key child  [?a] 'bar)
>>       child)
>>
>> :-(
>
> That can be fixed too.

Of course.  I think what I'm getting at is that the best fix is to
implement it inside `define-key` such that (define-key map
<k> :remove-nonparent-binding) does that you want.   It's probably easy
to implement there.

[ Where `:remove-nonparent-binding` is a candidate for a better name,
  of course.  ]

>>> but that breaks when `foo-next-thing' is renamed to `foo-forward'.
>>> And even if that never happens, it still complicates `foobar-mode-map',
>>> which now has a binding for `foo-next-thing', which isn't actually
>>> necessary because an identical binding exists in the parent keymap
>>> `foo-mode-map'.
>> How common is this case?
> When implementing an alternative set of key bindings across all of Emacs
> that diverge from the "standard Emacs key bindings" a lot (up to the
> scale of Vim but possibly not quite *that* drastically different), then
> it might be needed for essentially every keymap.

Interesting.  Maybe such scenarios would also benefit from a more
general "rewrite-keymap" operation, maybe by combining `map-keymap` and
a new `keymap-clear` operation that just empties a keymap completely.

>> So your notion of "no binding at all" can also be described as something
>> like "use the binding of the parent".
> Yes. (Or the default binding, or ...)
> remove(add(MAP KEY) KEY) == MAP

Do we need to distinguish

    (let ((map (make-sparse-keymap)))
      (define-key map [?a ?b] 'foo)
      (define-key map [?a ?b] :remove-nonparent-binding)
      map)

from

    (let ((map (make-sparse-keymap)))
      (define-key map [?a] (make-sparse-keymap))
      (define-key map [?a ?b] 'foo)
      (define-key map [?a ?b] :remove-nonparent-binding)
      map)

?


        Stefan

Re: Moving kbd to subr.el

[Juri Linkov]

> Can't we impose pretty much any syntax we like in new forms, such as
> 'defvar-keymap' and 'kbd-valid-p'?
>
> I'm looking at a fragment like this:
>
>    "P"         #'cvs-status-prev
> -  (kbd "M-n") #'cvs-status-next
> -  (kbd "M-p") #'cvs-status-prev
> +  ["M-n"]     #'cvs-status-next
> +  ["M-p"]     #'cvs-status-prev
>    "t"         #'cvs-status-cvstrees
>
> And I feel like it would be nice if we could avoid putting these
> strings in a vector.  Especially if we don't do it consistently.

It would be perfect if new defvar-keymap would use kbd-strict syntax.
Then replacing define-key with define-keymap will also replace
the string syntax - safely, and as we already discussed allowing
old syntax optionally by using a keyword like ':kbd nil'.

> At the same time, maybe I don't understand the overreaching plan.  Is
> the idea to be able to replace any use of (kbd "M-x") with ["M-x"]
> everywhere, including in 'define-key' et al?

Any use of (kbd "M-x") can't be replaced with ["M-x"].
For example, this use from (info "(elisp) Functions for Key Lookup")

  (lookup-key (current-global-map) (kbd "C-x C-f"))

can't be replaced with:

  (lookup-key (current-global-map) ["C-x C-f"])

Re: Moving kbd to subr.el

[Gregory Heytings]

>> At the same time, maybe I don't understand the overreaching plan.  Is 
>> the idea to be able to replace any use of (kbd "M-x") with ["M-x"] 
>> everywhere, including in 'define-key' et al?
>
> Any use of (kbd "M-x") can't be replaced with ["M-x"]. For example, this 
> use from (info "(elisp) Functions for Key Lookup")
>
>  (lookup-key (current-global-map) (kbd "C-x C-f"))
>
> can't be replaced with:
>
>  (lookup-key (current-global-map) ["C-x C-f"])
>

But note that with my patch it can be replaced with

(lookup-key (current-global-map) "C-x C-f")

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Any use of (kbd "M-x") can't be replaced with ["M-x"].
> For example, this use from (info "(elisp) Functions for Key Lookup")
>
>   (lookup-key (current-global-map) (kbd "C-x C-f"))
>
> can't be replaced with:
>
>   (lookup-key (current-global-map) ["C-x C-f"])

This is now fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1316 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:


You effectively re-asked for what I asked about six months ago --- we
really need a specification for what a valid key is that is not tangled
up in the edmacro implementation of parsing out key strings.

> Gregory Heytings <gregory@heytings.org> writes:
>
>> A suggestion:
>>
>> (kbd-valid-p "<mouse-1>")
>> (kbd-valid-p "<Scroll_Lock>")
>>
>> should return t, and
>
> Good point.  This does make one of the syntax checks either less
> effective, or the syntax is ambiguous.  I went with the latter, but I'm
> not sure that's the right thing to do here.
>
> The kbd syntax is
>
> "C-M-<return>"
>
> but allowing dashes inside the brackets means that 
>
> "<C-M-return>"
>
> should be parsed as the key named "C-M-return" (which isn't really
> possible).
>
> So I just added some special-casing to disallow the "<C-M-return>" form
> in kbd-valid-p.  We'll see... 
>
>> (kbd-valid-p "<123>")
>>
>> should (I think) return nil.  IOW, kbd-valid-p should use:
>
> I'm not sure -- can there be keys named "123"?  I don't know what the
> rules are here -- is there an authoritative source for the syntax of
> these names somewhere?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Moving kbd to subr.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 17 Oct 2021 21:55:58 +0200
> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org
> 
> > (kbd-valid-p "<123>")
> >
> > should (I think) return nil.  IOW, kbd-valid-p should use:
> 
> I'm not sure -- can there be keys named "123"?  I don't know what the
> rules are here -- is there an authoritative source for the syntax of
> these names somewhere?

AFAIU, the labels of those function keys can be anything.  Emacs
actually invents some such keys, see <sigusr1>.

Re: Moving kbd to subr.el

[Andreas Schwab]

On Okt 13 2021, Stefan Kangas wrote:

> +    (let ((case-fold-search nil)
> +          (len (length keys)) ; We won't alter keys in the loop below.
> +          (pos 0)
> +          (res []))
> +      (while (and (< pos len)
> +                  (string-match "[^ \t\n\f]+" keys pos))
> +        (let* ((word-beg (match-beginning 0))
> +               (word-end (match-end 0))
> +               (word (substring keys word-beg len))
> +               (times 1)
> +               key)
> +          ;; Try to catch events of the form "<as df>".
> +          (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
> +              (setq word (match-string 0 word)
> +                    pos (+ word-beg (match-end 0)))
> +            (setq word (substring keys word-beg word-end)
> +                  pos word-end))
> +          (when (string-match "\\([0-9]+\\)\\*." word)
> +            (setq times (string-to-number (substring word 0 (match-end 1))))
> +            (setq word (substring word (1+ (match-end 1)))))
> +          (cond ((string-match "^<<.+>>$" word)
> +                 (setq key (vconcat (if (eq (key-binding [?\M-x])
> +                                            'execute-extended-command)
> +                                        [?\M-x]
> +                                      (or (car (where-is-internal
> +                                                'execute-extended-command))
> +                                          [?\M-x]))
> +                                    (substring word 2 -2) "\r")))
> +                ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
> +                      (progn
> +                        (setq word (concat (match-string 1 word)
> +                                           (match-string 3 word)))
> +                        (not (string-match
> +                              "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
> +                              word))))
> +                 (setq key (list (intern word))))
> +                ((or (equal word "REM") (string-match "^;;" word))
> +                 (setq pos (string-match "$" keys pos)))
> +                (t
> +                 (let ((orig-word word) (prefix 0) (bits 0))
> +                   (while (string-match "^[ACHMsS]-." word)
> +                     (setq bits (+ bits (cdr (assq (aref word 0)
> +                                                   '((?A . ?\A-\^@) (?C . ?\C-\^@)
> +                                                     (?H . ?\H-\^@) (?M . ?\M-\^@)
> +                                                     (?s . ?\s-\^@) (?S . ?\S-\^@))))))
> +                     (setq prefix (+ prefix 2))
> +                     (setq word (substring word 2)))
> +                   (when (string-match "^\\^.$" word)
> +                     (setq bits (+ bits ?\C-\^@))
> +                     (setq prefix (1+ prefix))
> +                     (setq word (substring word 1)))
> +                   (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
> +                                              ("LFD" . "\n") ("TAB" . "\t")
> +                                              ("ESC" . "\e") ("SPC" . " ")
> +                                              ("DEL" . "\177")))))
> +                     (when found (setq word (cdr found))))
> +                   (when (string-match "^\\\\[0-7]+$" word)
> +                     (let ((n 0))
> +                       (dolist (ch (cdr (string-to-list word)))
> +                         (setq n (+ (* n 8) ch -48)))
> +                       (setq word (vector n))))
> +                   (cond ((= bits 0)
> +                          (setq key word))
> +                         ((and (= bits ?\M-\^@) (stringp word)
> +                               (string-match "^-?[0-9]+$" word))
> +                          (setq key (mapcar (lambda (x) (+ x bits))
> +                                            (append word nil))))
> +                         ((/= (length word) 1)
> +                          (error "%s must prefix a single character, not %s"
> +                                 (substring orig-word 0 prefix) word))
> +                         ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
> +                               ;; We used to accept . and ? here,
> +                               ;; but . is simply wrong,
> +                               ;; and C-? is not used (we use DEL instead).
> +                               (string-match "[@-_a-z]" word))
> +                          (setq key (list (+ bits (- ?\C-\^@)
> +                                             (logand (aref word 0) 31)))))
> +                         (t
> +                          (setq key (list (+ bits (aref word 0)))))))))
> +          (when key
> +            (dolist (_ (number-sequence 1 times))
> +              (setq res (vconcat res key))))))
> +      (when (and (>= (length res) 4)
> +                 (eq (aref res 0) ?\C-x)
> +                 (eq (aref res 1) ?\()
> +                 (eq (aref res (- (length res) 2)) ?\C-x)
> +                 (eq (aref res (- (length res) 1)) ?\)))
> +        (setq res (apply #'vector (let ((lres (append res nil)))
> +                                    ;; Remove the first and last two elements.
> +                                    (setq lres (cdr (cdr lres)))
> +                                    (nreverse lres)
> +                                    (setq lres (cdr (cdr lres)))
> +                                    (nreverse lres)
> +                                    lres))))
> +      (if (let ((ret t))
> +            (dolist (ch (append res nil))
> +              (unless (and (characterp ch)
> +                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
> +                             (and (>= ch2 0) (<= ch2 127))))
> +                (setq ret nil)))
> +            ret)
> +          (concat (mapcar (lambda (ch)
> +                            (if (= (logand ch ?\M-\^@) 0)
> +                                ch (+ ch 128)))
> +                          (append res nil)))
> +        res))))

That needs to be factored out.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Moving kbd to subr.el

[Stefan Kangas]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Okt 13 2021, Stefan Kangas wrote:
>
>> +    (let ((case-fold-search nil)
>> +          (len (length keys)) ; We won't alter keys in the loop below.
>> +          (pos 0)
>> +          (res []))
>> +      (while (and (< pos len)
>> +                  (string-match "[^ \t\n\f]+" keys pos))
>> +        (let* ((word-beg (match-beginning 0))
>> +               (word-end (match-end 0))
>> +               (word (substring keys word-beg len))
>> +               (times 1)
>> +               key)
>> +          ;; Try to catch events of the form "<as df>".
>> +          (if (string-match "\\`<[^ <>\t\n\f][^>\t\n\f]*>" word)
>> +              (setq word (match-string 0 word)
>> +                    pos (+ word-beg (match-end 0)))
>> +            (setq word (substring keys word-beg word-end)
>> +                  pos word-end))
>> +          (when (string-match "\\([0-9]+\\)\\*." word)
>> +            (setq times (string-to-number (substring word 0 (match-end 1))))
>> +            (setq word (substring word (1+ (match-end 1)))))
>> +          (cond ((string-match "^<<.+>>$" word)
>> +                 (setq key (vconcat (if (eq (key-binding [?\M-x])
>> +                                            'execute-extended-command)
>> +                                        [?\M-x]
>> +                                      (or (car (where-is-internal
>> +                                                'execute-extended-command))
>> +                                          [?\M-x]))
>> +                                    (substring word 2 -2) "\r")))
>> +                ((and (string-match "^\\(\\([ACHMsS]-\\)*\\)<\\(.+\\)>$" word)
>> +                      (progn
>> +                        (setq word (concat (match-string 1 word)
>> +                                           (match-string 3 word)))
>> +                        (not (string-match
>> +                              "\\<\\(NUL\\|RET\\|LFD\\|ESC\\|SPC\\|DEL\\)$"
>> +                              word))))
>> +                 (setq key (list (intern word))))
>> +                ((or (equal word "REM") (string-match "^;;" word))
>> +                 (setq pos (string-match "$" keys pos)))
>> +                (t
>> +                 (let ((orig-word word) (prefix 0) (bits 0))
>> +                   (while (string-match "^[ACHMsS]-." word)
>> +                     (setq bits (+ bits (cdr (assq (aref word 0)
>> +                                                   '((?A . ?\A-\^@) (?C . ?\C-\^@)
>> +                                                     (?H . ?\H-\^@) (?M . ?\M-\^@)
>> +                                                     (?s . ?\s-\^@) (?S . ?\S-\^@))))))
>> +                     (setq prefix (+ prefix 2))
>> +                     (setq word (substring word 2)))
>> +                   (when (string-match "^\\^.$" word)
>> +                     (setq bits (+ bits ?\C-\^@))
>> +                     (setq prefix (1+ prefix))
>> +                     (setq word (substring word 1)))
>> +                   (let ((found (assoc word '(("NUL" . "\0") ("RET" . "\r")
>> +                                              ("LFD" . "\n") ("TAB" . "\t")
>> +                                              ("ESC" . "\e") ("SPC" . " ")
>> +                                              ("DEL" . "\177")))))
>> +                     (when found (setq word (cdr found))))
>> +                   (when (string-match "^\\\\[0-7]+$" word)
>> +                     (let ((n 0))
>> +                       (dolist (ch (cdr (string-to-list word)))
>> +                         (setq n (+ (* n 8) ch -48)))
>> +                       (setq word (vector n))))
>> +                   (cond ((= bits 0)
>> +                          (setq key word))
>> +                         ((and (= bits ?\M-\^@) (stringp word)
>> +                               (string-match "^-?[0-9]+$" word))
>> +                          (setq key (mapcar (lambda (x) (+ x bits))
>> +                                            (append word nil))))
>> +                         ((/= (length word) 1)
>> +                          (error "%s must prefix a single character, not %s"
>> +                                 (substring orig-word 0 prefix) word))
>> +                         ((and (/= (logand bits ?\C-\^@) 0) (stringp word)
>> +                               ;; We used to accept . and ? here,
>> +                               ;; but . is simply wrong,
>> +                               ;; and C-? is not used (we use DEL instead).
>> +                               (string-match "[@-_a-z]" word))
>> +                          (setq key (list (+ bits (- ?\C-\^@)
>> +                                             (logand (aref word 0) 31)))))
>> +                         (t
>> +                          (setq key (list (+ bits (aref word 0)))))))))
>> +          (when key
>> +            (dolist (_ (number-sequence 1 times))
>> +              (setq res (vconcat res key))))))
>> +      (when (and (>= (length res) 4)
>> +                 (eq (aref res 0) ?\C-x)
>> +                 (eq (aref res 1) ?\()
>> +                 (eq (aref res (- (length res) 2)) ?\C-x)
>> +                 (eq (aref res (- (length res) 1)) ?\)))
>> +        (setq res (apply #'vector (let ((lres (append res nil)))
>> +                                    ;; Remove the first and last two elements.
>> +                                    (setq lres (cdr (cdr lres)))
>> +                                    (nreverse lres)
>> +                                    (setq lres (cdr (cdr lres)))
>> +                                    (nreverse lres)
>> +                                    lres))))
>> +      (if (let ((ret t))
>> +            (dolist (ch (append res nil))
>> +              (unless (and (characterp ch)
>> +                           (let ((ch2 (logand ch (lognot ?\M-\^@))))
>> +                             (and (>= ch2 0) (<= ch2 127))))
>> +                (setq ret nil)))
>> +            ret)
>> +          (concat (mapcar (lambda (ch)
>> +                            (if (= (logand ch ?\M-\^@) 0)
>> +                                ch (+ ch 128)))
>> +                          (append res nil)))
>> +        res))))
>
> That needs to be factored out.

Sorry, which part are you referring to?  All of the above?

Re: Moving kbd to subr.el

[Andreas Schwab]

On Okt 14 2021, Stefan Kangas wrote:

> Sorry, which part are you referring to?  All of the above?

Yes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Sorry, which part are you referring to?  All of the above?
>
> Yes.

Don't see the point in moving the entirety of a function body to another
function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Moving kbd to subr.el

[Andreas Schwab]

On Okt 14 2021, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>> Sorry, which part are you referring to?  All of the above?
>>
>> Yes.
>
> Don't see the point in moving the entirety of a function body to another
> function.

That's not what factoring is about.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Moving kbd to subr.el

[Stefan Kangas]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Don't see the point in moving the entirety of a function body to another
>> function.
>
> That's not what factoring is about.

I understand that one-liners is your style, but I find it too terse to
follow here.  That's unfortunate, because I would like to understand
what you are saying.

In your first message you wrote "That needs to be factored out."  When
someone says "factor out", I understand this to mean that you move some
specific part of one function into another function.  Moreover, the word
"that" seems to refer to only one part of the function.

Now you seem to be talking about refactoring, which is a term that I
understand to cover a wider set of types of changes.

Could you perhaps elaborate on what you mean here?

Re: Moving kbd to subr.el

[Dmitry Gutov]

On 14.10.2021 16:10, Stefan Kangas wrote:
> Andreas Schwab<schwab@linux-m68k.org>  writes:
> 
>>> Don't see the point in moving the entirety of a function body to another
>>> function.
>> That's not what factoring is about.
> I understand that one-liners is your style, but I find it too terse to
> follow here.  That's unfortunate, because I would like to understand
> what you are saying.

Asking Andreas for clarifications is unfortunately useless.

One might as well ignore those of his messages where the meaning is not 
immediately apparent.

Re: Moving kbd to subr.el

[dick]

DG> Asking Andreas for clarifications is unfortunately useless.

I would like to go on record as being a massive fan of this man's tersity.

In the words of another surly programmer, talk is cheap, show me the code.

Re: Moving kbd to subr.el

[Dmitry Gutov]

On 14.10.2021 17:05, dick wrote:
> I would like to go on record as being a massive fan of this man's tersity.

Being terse is fun.

But when nobody can understand you, it's also rude.

Re: Moving kbd to subr.el

[dick]

Length of communication is mildly *anti-correlated* to comprehensibility.  True
in life, true in code.  Of course diminishing returns, and all that.

Re: Moving kbd to subr.el

[Lars Ingebrigtsen]

dick <dick.r.chiang@gmail.com> writes:

> Length of communication is mildly *anti-correlated* to comprehensibility.

K.

Re: Moving kbd to subr.el

[Gregory Heytings]

Representing key sequences (was: master 859190f 2/3: Convert some keymaps to defvar-keymap)

[Stefan Monnier]

Currently, we have 2 "builtin/native" representation of key sequences:

(A) strings (where every char represents an event)
(B) vectors of events

I believe they are both unpopular, but (A) really sucks (it only
handles a small subset of possible key-sequences).

There are two "standard" alternatives:
(C) string (passed to `kbd`).
(D) vectors of lists (using the XEmacs syntax).

I'd be in favor of promoting both (C) and (D) while phasing out both (A)
and (B).


        Stefan

Re: Representing key sequences (was: master 859190f 2/3: Convert some keymaps to defvar-keymap)

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Currently, we have 2 "builtin/native" representation of key sequences:
>
> (A) strings (where every char represents an event)
> (B) vectors of events
>
> I believe they are both unpopular, but (A) really sucks (it only
> handles a small subset of possible key-sequences).
>
> There are two "standard" alternatives:
> (C) string (passed to `kbd`).
> (D) vectors of lists (using the XEmacs syntax).
>
> I'd be in favor of promoting both (C) and (D) while phasing out both (A)
> and (B).

I agree with regards to A and C, but I was not aware of the difference
between B and D.  Could you show an example of the difference between
B and D, and explain how the latter is more preferable?  Also, in
which situations can we currently use B but not D?

Re: Representing key sequences

[Stefan Monnier]

> I agree with regards to A and C, but I was not aware of the difference
> between B and D.  Could you show an example of the difference between
> B and D, and explain how the latter is more preferable?

(B)  is for example  [?\C-\M-x C-home]
(D)  would be        [(control meta x) (control home)]

Notice how you don't need to know that one is a char whereas the other
is a "non-char key".

> Also, in which situations can we currently use B but not D?

(B) and derivatives is used internally everywhere
(e.g. `read-key-sequence`), whereas (D) is only supported for
`define-key` and friends.



        Stefan

Re: Representing key sequences

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> (B)  is for example  [?\C-\M-x C-home]
> (D)  would be        [(control meta x) (control home)]

We could add a fifth syntax.  :-/

["M-C-x C-<home>"] -- which would be a shorter way to write
(kbd "M-C-x C-<home>").

Hang on...  would

[M-C-x C-<home>]

work as a syntax?  The Emacs Lisp symbol syntax is pretty permissive,
but...  hm...  And it might be ambiguous wrt. (B). 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Representing key sequences

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There are two "standard" alternatives:
> (C) string (passed to `kbd`).
> (D) vectors of lists (using the XEmacs syntax).
>
> I'd be in favor of promoting both (C) and (D) while phasing out both (A)
> and (B).

I'm in favour of promoting (C) and (D) (and perhaps making
`define-keymap' not do (A), as Stefan K. proposed), but phasing out (A)
would be difficult.  (Unless you mean "not promoting (A)" as "phasing
out (A)".)

I don't think (B) is used much...  OK, it's used more than I thought --
209 times in the Emacs tree.  Things like:

(define-key global-map [?\s-~] 'ns-prev-frame)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Representing key sequences

[Andreas Schwab]

On Okt 13 2021, Lars Ingebrigtsen wrote:

> I don't think (B) is used much...  OK, it's used more than I thought --
> 209 times in the Emacs tree.

And countless times in user's init files.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> Aha.  Now I understand the argument.  But surely that's pretty minor, 
>> given that we can just document this difference?  People might 
>> appreciate the easier to read syntax many times more than they will 
>> struggle with this minor additional complexity.
>
> Well, we have a bunch of different key syntaxes, and two of them are 
> strings and therefore aren't marked as syntactically different.
>

But their syntaxes are different, aren't they?

>> It seems somewhat unfortunate to me that we are effectively doubling 
>> down on the mistakes of the past.  I'd rather take one step forward 
>> now, in the hope that we can do something about "define-key" later.
>
> I don't think that's a forlorn hope.  We'd have to introduce a new 
> function.
>

Is this not possible as follows (it's a POC), without introducing a new 
function?

diff --git a/src/keymap.c b/src/keymap.c
index be45d2be1e..7cad7cb4d1 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1059,6 +1059,11 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 
3, 0,
  {
    bool metized = false;

+  if (STRINGP (key) &&
+      (strstr (SSDATA (key), "C-") || strstr (SSDATA (key), "M-")) &&
+      !NILP (Ffboundp (Qkbd)))
+    key = safe_call1 (Qkbd, key);
+
    keymap = get_keymap (keymap, 1, 1);

    ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
@@ -3261,4 +3266,6 @@ syms_of_keymap (void)
    defsubr (&Stext_char_description);
    defsubr (&Swhere_is_internal);
    defsubr (&Sdescribe_buffer_bindings);
+
+  DEFSYM (Qkbd, "kbd");
  }

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> Well, we have a bunch of different key syntaxes, and two of them are
>> strings and therefore aren't marked as syntactically different.
>>
>
> But their syntaxes are different, aren't they?

(local-set-key "C-i" (lambda () (interactive) (message "hello")))
C-i
"hello"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>>> Well, we have a bunch of different key syntaxes, and two of them are 
>>> strings and therefore aren't marked as syntactically different.
>>
>> But their syntaxes are different, aren't they?
>
> (local-set-key "C-i" (lambda () (interactive) (message "hello")))
> C-i
> "hello"
>

Yes, of course, but is this case not... a bit theoretical?  The syntax to 
fix that corner case would be "C - i".

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, of course, but is this case not... a bit theoretical?  The syntax
> to fix that corner case would be "C - i".

It's an unlikely key binding, but it's ambiguous, as claimed. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 08:54:20 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org
> 
> Is this not possible as follows (it's a POC), without introducing a new 
> function?
> 
> diff --git a/src/keymap.c b/src/keymap.c
> index be45d2be1e..7cad7cb4d1 100644
> --- a/src/keymap.c
> +++ b/src/keymap.c
> @@ -1059,6 +1059,11 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 
> 3, 0,
>   {
>     bool metized = false;
> 
> +  if (STRINGP (key) &&
> +      (strstr (SSDATA (key), "C-") || strstr (SSDATA (key), "M-")) &&
> +      !NILP (Ffboundp (Qkbd)))
> +    key = safe_call1 (Qkbd, key);
> +
>     keymap = get_keymap (keymap, 1, 1);
> 
>     ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
> @@ -3261,4 +3266,6 @@ syms_of_keymap (void)
>     defsubr (&Stext_char_description);
>     defsubr (&Swhere_is_internal);
>     defsubr (&Sdescribe_buffer_bindings);
> +
> +  DEFSYM (Qkbd, "kbd");
>   }

If the "kbd" call fails for some reason, safe_call1 will return nil,
and what will that do to the rest of the code?

Also, I think doing this effectively means preloading kbd.el, because
define-key is used in many places in packages we preload.  Or am I
missing something?

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>
> If the "kbd" call fails for some reason, safe_call1 will return nil, and 
> what will that do to the rest of the code?
>

That code was a short proof of concept, to initiate a discussion.  If the 
idea is okay, I'll work on it to fix this problem (and possibly others).

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 13:05:16 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: larsi@gnus.org, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > If the "kbd" call fails for some reason, safe_call1 will return nil, and 
> > what will that do to the rest of the code?
> 
> That code was a short proof of concept, to initiate a discussion.  If the 
> idea is okay, I'll work on it to fix this problem (and possibly others).

Ah, okay.  Apologies for my misunderstanding.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>>> If the "kbd" call fails for some reason, safe_call1 will return nil, 
>>> and what will that do to the rest of the code?
>>
>> That code was a short proof of concept, to initiate a discussion.  If 
>> the idea is okay, I'll work on it to fix this problem (and possibly 
>> others).
>
> Ah, okay.  Apologies for my misunderstanding.
>

No need to apologize.  But what do you (and others) think of the idea? 
It would be a (IMO elegant) way to "phase out strings (where every char 
represents an event)".

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> No need to apologize.  But what do you (and others) think of the idea?
> It would be a (IMO elegant) way to "phase out strings (where every
> char represents an event)".

We don't want our basic building blocks to be DWIM-ey, but instead have
well-documented, reliable interfaces, and certainly not change those
interfaces in subtle ways.  So changing `define-key' in this way is a no
go.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We don't want our basic building blocks to be DWIM-ey, but instead have
> well-documented, reliable interfaces, and certainly not change those
> interfaces in subtle ways.  So changing `define-key' in this way is a no
> go.

I agree with Lars here.

But how about a new function (e.g. named 'bind-key') that defaults to
kbd-syntax?  Then we could encourage its use in new code and init
files.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> We don't want our basic building blocks to be DWIM-ey, but instead have 
>> well-documented, reliable interfaces, and certainly not change those 
>> interfaces in subtle ways.  So changing `define-key' in this way is a 
>> no go.
>
> I agree with Lars here.
>

I really don't see how this could break anything, but okay.

>
> But how about a new function (e.g. named 'bind-key') that defaults to 
> kbd-syntax?  Then we could encourage its use in new code and init files.
>

Yes.  But then you'd need another set of new functions, "bind-key-after", 
"global-bind-key", "local-bind-key", "global-unbind-key", 
"local-unbind-key".  And another one for "lookup-key", too.  A rather 
confusing situation, IMO.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 14:28:17 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> No need to apologize.  But what do you (and others) think of the idea? 
> It would be a (IMO elegant) way to "phase out strings (where every char 
> represents an event)".

What do you intend to do with the "effectively preload kbd.el" part of
my comments?  If you indeed intend to preload kbd.el, that could be a
bummer, I think.  If you have other ideas, please tell.

IOW, I think the problem is not the idera, the problem is how to get
all the details right.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> No need to apologize.  But what do you (and others) think of the idea? 
>> It would be a (IMO elegant) way to "phase out strings (where every char 
>> represents an event)".
>
> What do you intend to do with the "effectively preload kbd.el" part of 
> my comments?  If you indeed intend to preload kbd.el, that could be a 
> bummer, I think.  If you have other ideas, please tell.
>

Well, Lars (and Stefan K) already replied that it's a no go, so I don't 
think it's useful to explore this further.

To reply to your question anyway: perhaps I'm misunderstanding something, 
but I don't see why this would in itself imply preloading anything new. 
The (fboundp 'kbd) check, and checking that the return value of safe_call1 
is non-nil (which I didn't do in the proof of concept) means that this 
would not have any effect until subr.el and edmacro.el (there's no 
"kbd.el", so I guess you mean "edmacro.el") are loaded.  Here's a slightly 
more elaborate proof of concept:

diff --git a/src/keymap.c b/src/keymap.c
index be45d2be1e..8e0a99a4b0 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1059,6 +1059,15 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 
3, 0,
  {
    bool metized = false;

+  Lisp_Object kbd_key;
+  if (STRINGP (key) &&
+      (strstr (SSDATA (key), "C-") || strstr (SSDATA (key), "M-") ||
+       strstr (SSDATA (key), "S-") || strstr (SSDATA (key), "H-") ||
+       strstr (SSDATA (key), "s-")) &&
+      !NILP (Ffboundp (Qkbd)) &&
+      !NILP (kbd_key = safe_call1 (Qkbd, key)))
+    key = kbd_key;
+
    keymap = get_keymap (keymap, 1, 1);

    ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
@@ -3261,4 +3270,6 @@ syms_of_keymap (void)
    defsubr (&Stext_char_description);
    defsubr (&Swhere_is_internal);
    defsubr (&Sdescribe_buffer_bindings);
+
+  DEFSYM (Qkbd, "kbd");
  }

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 16:07:42 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: larsi@gnus.org, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> To reply to your question anyway: perhaps I'm misunderstanding something, 
> but I don't see why this would in itself imply preloading anything new. 
> The (fboundp 'kbd) check, and checking that the return value of safe_call1 
> is non-nil (which I didn't do in the proof of concept) means that this 
> would not have any effect until subr.el and edmacro.el (there's no 
> "kbd.el", so I guess you mean "edmacro.el") are loaded.

I understand, but edmacro is not preloaded, and files we do preload,
like bindings.el, call define-key all over the place.  Letting all
those calls fail, albeit silently, would not be useful, not if we want
to be able to use 'kbd' syntax freely in preloaded files.  So I'm not
sure I understand how your proposal will work in practice.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> To reply to your question anyway: perhaps I'm misunderstanding 
>> something, but I don't see why this would in itself imply preloading 
>> anything new. The (fboundp 'kbd) check, and checking that the return 
>> value of safe_call1 is non-nil (which I didn't do in the proof of 
>> concept) means that this would not have any effect until subr.el and 
>> edmacro.el (there's no "kbd.el", so I guess you mean "edmacro.el") are 
>> loaded.
>
> I understand, but edmacro is not preloaded, and files we do preload, 
> like bindings.el, call define-key all over the place.  Letting all those 
> calls fail, albeit silently, would not be useful, not if we want to be 
> able to use 'kbd' syntax freely in preloaded files.  So I'm not sure I 
> understand how your proposal will work in practice.
>

The question (at least as I understood is) was to make it possible for 
users (in their init files) and third-party packages to use a more 
readable syntax for key bindings, without wrapping each key binding in a 
call to kbd.  That would have been a first step towards phasing out the 
"strings where every char represents an event" syntax.  Perhaps the check 
for (fboundp 'kbd) could have been replaced by a (will_bootstrap_p () || 
will_dump_p ()) check to avoid the unnecessary calls during bootstrap.

A second step would be to preload edmacro-parse-keys, to make it possible 
to use the kbd syntax in other preloaded files too.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> I understand, but edmacro is not preloaded, and files we do preload, 
>> like bindings.el, call define-key all over the place.  Letting all 
>> those calls fail, albeit silently, would not be useful, not if we want 
>> to be able to use 'kbd' syntax freely in preloaded files.  So I'm not 
>> sure I understand how your proposal will work in practice.
>
> The question (at least as I understood is) was to make it possible for 
> users (in their init files) and third-party packages to use a more 
> readable syntax for key bindings, without wrapping each key binding in a 
> call to kbd.  That would have been a first step towards phasing out the 
> "strings where every char represents an event" syntax.  Perhaps the 
> check for (fboundp 'kbd) could have been replaced by a (will_bootstrap_p 
> () || will_dump_p ()) check to avoid the unnecessary calls during 
> bootstrap.
>
> A second step would be to preload edmacro-parse-keys, to make it 
> possible to use the kbd syntax in other preloaded files too.
>

Now that Stefan K has written a patch to move kbd and edmacro-parse-keys 
to subr.el, the distinction above is not necessary anymore.  With the 
proposed patch (which would probably need some more work) it would be 
possible to use the kbd syntax in define-key and friends without 
explicitly calling kbd.  But again I don't really see why we're discussing 
this, given that Lars and Stefan K already said it's a no go.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 22:55:01 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: larsi@gnus.org, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> But again I don't really see why we're discussing this

Because you asked a question, and I wanted to explain my rationale.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> Date: Wed, 13 Oct 2021 21:53:40 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: larsi@gnus.org, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > I understand, but edmacro is not preloaded, and files we do preload, 
> > like bindings.el, call define-key all over the place.  Letting all those 
> > calls fail, albeit silently, would not be useful, not if we want to be 
> > able to use 'kbd' syntax freely in preloaded files.  So I'm not sure I 
> > understand how your proposal will work in practice.
> 
> The question (at least as I understood is) was to make it possible for 
> users (in their init files) and third-party packages to use a more 
> readable syntax for key bindings, without wrapping each key binding in a 
> call to kbd.

No, we wanted ourselves to be able to use that, not just let users do
it in their init files.

> A second step would be to preload edmacro-parse-keys, to make it possible 
> to use the kbd syntax in other preloaded files too.

And that, from my POV, is a main drawback of this proposal: preloading
edmacro will pull in some non-trivial code and support libraries,
which is best avoided.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> The question (at least as I understood is) was to make it possible for 
>> users (in their init files) and third-party packages to use a more 
>> readable syntax for key bindings, without wrapping each key binding in 
>> a call to kbd.
>
> No, we wanted ourselves to be able to use that, not just let users do it 
> in their init files.
>

If by "that" you mean "use a more readable syntax for key bindings, 
without wrapping each key binding in a call to kbd", then this is not what 
we will have, even with Stefan K's patch, with which it will be possible 
to use (kbd ...) in preloaded files.  To have "that", it would be 
necessary to go one step further.  Which was the main point of my 
proposal.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> If by "that" you mean "use a more readable syntax for key bindings,
> without wrapping each key binding in a call to kbd", then this is not what
> we will have, even with Stefan K's patch, with which it will be possible
> to use (kbd ...) in preloaded files.  To have "that", it would be
> necessary to go one step further.  Which was the main point of my
> proposal.

Did you see Richard's reply in this thread?  I found it interesting and
worth thinking about, especially the part where he says "maybe we should
fully adopt a cleaner interface for specifying a key to bind".

I think it would be useful if we could come up with some ideas for what
something like that could look like.  Of course, nothing is a given, but
a good enough proposal might convince.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Did you see Richard's reply in this thread?  I found it interesting and
> worth thinking about, especially the part where he says "maybe we should
> fully adopt a cleaner interface for specifying a key to bind".

#k"C-x C-c"  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> If by "that" you mean "use a more readable syntax for key bindings, 
>> without wrapping each key binding in a call to kbd", then this is not 
>> what we will have, even with Stefan K's patch, with which it will be 
>> possible to use (kbd ...) in preloaded files.  To have "that", it would 
>> be necessary to go one step further.  Which was the main point of my 
>> proposal.
>
> Did you see Richard's reply in this thread?  I found it interesting and 
> worth thinking about, especially the part where he says "maybe we should 
> fully adopt a cleaner interface for specifying a key to bind".
>

Yes, I've seen his reply.  And I do not see what could be cleaner than the 
kbd syntax, which has AFAIK been adopted everywhere, including in the 
tutorial, manuals, error messages, help buffers, and so forth.

>
> I think it would be useful if we could come up with some ideas for what 
> something like that could look like.  Of course, nothing is a given, but 
> a good enough proposal might convince.
>

The only drawback of the proposal is that those who use for example 
(define-key some-map "C-" some-command) to mean "bind capital letter C 
followed by minus" would have to insert a space between "C" and "-" to 
avoid the ambiguity.  Frankly, I don't see how this minor, and as I've 
said almost theoretical problem, should force us to create yet another 
syntax and yet another set of key binding functions.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> The only drawback of the proposal is that those who use for example
> (define-key some-map "C-" some-command) to mean "bind capital letter C
> followed by minus" would have to insert a space between "C" and "-" to
> avoid the ambiguity.

(kbd "f p")
=> "fp"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> The only drawback of the proposal is that those who use for example 
>> (define-key some-map "C-" some-command) to mean "bind capital letter C 
>> followed by minus" would have to insert a space between "C" and "-" to 
>> avoid the ambiguity.
>
> (kbd "f p")
> => "fp"
>

I'm not sure what you mean, but while trying to understand what you mean I 
realized that the paragraph above is not correct.  The correct version is:

The only drawback of the proposal is that those who use for example 
(define-key some-map "C-" some-command) to mean "bind capital letter C 
followed by minus" would have to use a vector instead: (define-key 
some-map [(C) (-)] some-command).  Frankly, I don't see how this minor, 
and as I've said almost theoretical problem, should force us to create yet 
another syntax and yet another set of key binding functions.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> (kbd "f p")
>> => "fp"
>>
>
> I'm not sure what you mean, but while trying to understand what you
> mean I realized that the paragraph above is not correct. 

The three key sequence `f' `SPC' and `p' is a perfectly valid thing to
feed to `define-key'.  If you run it through `kbd' first, you get a two
key sequence.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>>> (kbd "f p")
>>> => "fp"
>>
>> I'm not sure what you mean, but while trying to understand what you 
>> mean I realized that the paragraph above is not correct.
>
> The three key sequence `f' `SPC' and `p' is a perfectly valid thing to 
> feed to `define-key'.  If you run it through `kbd' first, you get a two 
> key sequence.
>

But such a key sequence would not be transformed by kbd, because it does 
not contain "C-" or something similar.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>>>> (kbd "f p")
>>>> => "fp"
>>>
>>> I'm not sure what you mean, but while trying to understand what you
>>> mean I realized that the paragraph above is not correct.
>>
>> The three key sequence `f' `SPC' and `p' is a perfectly valid thing
>> to feed to `define-key'.  If you run it through `kbd' first, you get
>> a two key sequence.
>>
>
> But such a key sequence would not be transformed by kbd, because it
> does not contain "C-" or something similar.

The thing I pasted up there was a literal evaluation of the form.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> But such a key sequence would not be transformed by kbd, because it 
>> does not contain "C-" or something similar.
>
> The thing I pasted up there was a literal evaluation of the form.
>

Sorry for the confusion, what I said was unclear: with the proposed (proof 
of concept) patch (see below), such a sequence would not be transformed by 
kbd, because it does not contain "C-" or something similar.

diff --git a/src/keymap.c b/src/keymap.c
index be45d2be1e..8e0a99a4b0 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1059,6 +1059,15 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
  {
    bool metized = false;

+  Lisp_Object kbd_key;
+  if (STRINGP (key) &&
+      (strstr (SSDATA (key), "C-") || strstr (SSDATA (key), "M-") ||
+       strstr (SSDATA (key), "S-") || strstr (SSDATA (key), "H-") ||
+       strstr (SSDATA (key), "s-")) &&
+      !NILP (Ffboundp (Qkbd)) &&
+      !NILP (kbd_key = safe_call1 (Qkbd, key)))
+    key = kbd_key;
+
    keymap = get_keymap (keymap, 1, 1);

    ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
@@ -3261,4 +3270,6 @@ syms_of_keymap (void)
    defsubr (&Stext_char_description);
    defsubr (&Swhere_is_internal);
    defsubr (&Sdescribe_buffer_bindings);
+
+  DEFSYM (Qkbd, "kbd");
  }

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Sorry for the confusion, what I said was unclear: with the proposed
> (proof of concept) patch (see below), such a sequence would not be
> transformed by kbd, because it does not contain "C-" or something
> similar.

That's even more confusing.  If you want to only use kbd syntax, then
you have to use kbd explicitly for some key bindings (if you want to
bind "fp", for instance), but not for others.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>> Sorry for the confusion, what I said was unclear: with the proposed 
>> (proof of concept) patch (see below), such a sequence would not be 
>> transformed by kbd, because it does not contain "C-" or something 
>> similar.
>
> That's even more confusing.  If you want to only use kbd syntax, then 
> you have to use kbd explicitly for some key bindings (if you want to 
> bind "fp", for instance), but not for others.
>

(kbd "fp") == "fp", so why would you need to use kbd explicitly to bind 
"fp"?  With the patch:

(local-set-key "f" some-command) binds f
(local-set-key "fp" some-command) binds f p
(local-set-key "f p" some-command) binds f SPC p
(local-set-key "C-p" some-command) binds C-p
(local-set-key "M-p" some-command) binds M-p
(local-set-key "C-M-p" some-command) binds C-M-p

But if you want to bind C - p (capital C, dash, p) you have to use a 
vector:

(local-set-key [(C) (-) (p)] some-command) binds C - p

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> That's even more confusing.  If you want to only use kbd syntax,
>> then you have to use kbd explicitly for some key bindings (if you
>> want to bind "fp", for instance), but not for others.
>
> (kbd "fp") == "fp", so why would you need to use kbd explicitly to
> bind "fp"?

The kbd syntax for `f' `p' is "f p".

---
f p runs the command (lambda nil (interactive)), which is an
interactive Lisp function.

It is bound to f p.
---

So people that want to use kbd syntax to bind `f' `p', and `define-key'
runs other things through `kbd' automatically, they will write:

(define-key "f p" ...)

and be confused.

Instead they'll have to write

(define-key (kbd "f p") ...)
(define-key "C-c C-c" ...)

and it's all DWIM mess.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>
> So people that want to use kbd syntax to bind `f' `p', and `define-key' 
> runs other things through `kbd' automatically, they will write:
>

Not if the allowed syntax if properly defined in the docstring of 
define-key.  Something like:

KEY is a string or a vector of symbols and characters, representing a 
sequence of keystrokes and events.  Non-ASCII characters with codes above 
127 (such as ISO Latin-1) can be represented by vectors.  If KEY contains 
one or more modifiers, it is first processed by `kbd', which see.

>
> and it's all DWIM mess.
>

I know you don't like the idea ;-)  But thank you for giving me the 
opportunity to make the proposal as clear as possible.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, I've seen his reply.  And I do not see what could be cleaner than the
> kbd syntax, which has AFAIK been adopted everywhere, including in the
> tutorial, manuals, error messages, help buffers, and so forth.

For me, it's a no-brainer that we would want to bind keys in the same
way as we display them.

However, that style as implemented by 'kbd' is not without its problems.
It is too allowing in some cases where it would be better to be more
strict:

    (kbd "f 1")       => "f1"       ; space is not mandatory
    (kbd "f1")        => "f1"       ; user intended [f1], got "f 1"
    (kbd "<return>")  => [return]
    (kbd "return")    => "return"   ; as above
    (kbd "f ;; foo")  => "f"
    (kbd "f REM foo") => "f"
    (kbd "8*a")       => "aaaaaaaa"
    (kbd "\C-a")      => "^A"       ; fine, but could be disallowed

Stefan Monnier says that we should also be able to say things like
[(control x)], and I have no objections to that.

So the question is not about the format of keybindings, as AFAICT there
seems to exist more or less a consensus around it.  The question is what
API would be useful.

> Frankly, I don't see how this minor, and as I've said almost
> theoretical problem, should force us to create yet another syntax and
> yet another set of key binding functions.

Ambiguity is not a good property to have in our most fundamental
interfaces, IMO.  I think we should not try to retro-fit any DWIM stuff
on the old one, as that will lead to various problems.  It would be
better to provide a new one and promote that as a replacement.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> However, that style as implemented by 'kbd' is not without its problems.
> It is too allowing in some cases where it would be better to be more
> strict:
>
>     (kbd "f 1")       => "f1"       ; space is not mandatory
>     (kbd "f1")        => "f1"       ; user intended [f1], got "f 1"
>     (kbd "<return>")  => [return]
>     (kbd "return")    => "return"   ; as above
>     (kbd "f ;; foo")  => "f"
>     (kbd "f REM foo") => "f"
>     (kbd "8*a")       => "aaaaaaaa"
>     (kbd "\C-a")      => "^A"       ; fine, but could be disallowed

Yeah, a stricter version of kbd would definitely be nice here -- giving
the developer early feedback on invalid things in the argument would be
very helpful.

If we introduced a fifth syntax (based on the kbd syntax, but not a
plain string), we could make that be stricter.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>
> Yeah, a stricter version of kbd would definitely be nice here
>

There's at least something on which we agree ;-)

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If we introduced a fifth syntax (based on the kbd syntax, but not a
> plain string), we could make that be stricter.

I mentioned

["C-s C-s"]

before, which would be trivial to add.  But we could splurge for a
reader syntax for keys.  It seems a bit extravagant, but keys are
fundamental to Emacs, so perhaps it's warranted.

#{C-s C-s}

for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Monnier]

Lars Ingebrigtsen [2021-10-14 22:01:19] wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> If we introduced a fifth syntax (based on the kbd syntax, but not a
>> plain string), we could make that be stricter.
>
> I mentioned
>
> ["C-s C-s"]
>
> before, which would be trivial to add.  But we could splurge for a
> reader syntax for keys.  It seems a bit extravagant, but keys are
> fundamental to Emacs, so perhaps it's warranted.
>
> #{C-s C-s}
>
> for instance.

I also like the suggestion to allow

    [C-s C-s]


-- Stefan

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I also like the suggestion to allow
>
>     [C-s C-s]

Yes, isn't that the best one, even?  It certainly looks less noisy
than the proposed alternatives, and it also has the nice property that
it's just a vector so you can manipulate it in all the ways you'd
expect.  For that reason, it also stands out just enough from a
regular list and the surrounding code.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I also like the suggestion to allow
>>
>>     [C-s C-s]
>
> Yes, isn't that the best one, even?  It certainly looks less noisy
> than the proposed alternatives, and it also has the nice property that
> it's just a vector so you can manipulate it in all the ways you'd
> expect.  For that reason, it also stands out just enough from a
> regular list and the surrounding code.

I assumed that it would be ambiguous with the (B) syntax, but I didn't
really look into it.  Let's do some grepping...

(define-key map [next]  'calendar-scroll-left-three-months)
(define-key map [left]  'calendar-backward-day)

These are fine...

(define-key map [remap undo] 'calc-undo)
(define-key map [vertical-scroll-bar mouse-1]

That's OK.

(define-key map [tab] 'todo-next-button)

Hm, the kbd syntax would be

(define-key map [TAB] 'todo-next-button)

but I guess it's fine...

(define-key function-key-map [C-delete] [?\M-d])

That's C-<delete> in kbd syntax -- I guess it's fine if we accept both,
but then we lose the opportunity to be stricter with the syntax.

(define-key map [M-clear] [?\M-\C-l])

Ditto.

(defvar vc-git-stash-menu-map
  (let ((map (make-sparse-keymap "Git Stash")))
    (define-key map [sn]
      '(menu-item "Snapshot Stash" vc-git-stash-snapshot
		  :help "Snapshot stash"))

Oh, yeah, I had totally forgotten that this is how menus are defined.
To it's ambiguous here -- the thing in [] could be anything, including
[s], which kdb would interpret as the key "s".

This form is limited to menu items, though, so perhaps it could be made
to work (i.e., if the DEF is a menu item, then we have different logic).

So I'm not sure.  It's not 100% straightforward, but it could work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, yeah, I had totally forgotten that this is how menus are defined.
> To it's ambiguous here -- the thing in [] could be anything, including
> [s], which kdb would interpret as the key "s".
>
> This form is limited to menu items, though, so perhaps it could be made
> to work (i.e., if the DEF is a menu item, then we have different logic).

No, this is valid code:

(local-set-key "f"
      '(menu-item "Create Named Stash" vc-git-stash
		  :help "Create named stash"))

It's a very odd way to call `vc-git-stash', but it's possible, I guess.

So the [f] syntax would be ambiguous.

(local-set-key [f]
      '(menu-item "Create Named Stash" vc-git-stash
		  :help "Create named stash"))

currently doesn't set any keys, but if we interpret [f] as a kbd
sequence, it would bind the `f' key.  So this syntax might not fly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No, this is valid code:
>
> (local-set-key "f"
>       '(menu-item "Create Named Stash" vc-git-stash
> 		  :help "Create named stash"))
>
> It's a very odd way to call `vc-git-stash', but it's possible, I guess.
>
> So the [f] syntax would be ambiguous.
>
> (local-set-key [f]
>       '(menu-item "Create Named Stash" vc-git-stash
> 		  :help "Create named stash"))
>
> currently doesn't set any keys, but if we interpret [f] as a kbd
> sequence, it would bind the `f' key.  So this syntax might not fly.

I imagine that this would be a new function, so in that case it seems to
me that backwards compatibility is not a concern.  Are you also
discussing a new function here?

On another note, I find it weird that we can bind keys to menu-items,
but that is the only way to get at some functionality.  This should
probably be fixed.

On a third note, why don't we just provide a better interface for
creating menu items that is not based on pretending that a menu item
like a key?  Do we need to leak that implementation detail for some
didactic reason, or something?

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I imagine that this would be a new function, so in that case it seems to
> me that backwards compatibility is not a concern.  Are you also
> discussing a new function here?

No, it's a new syntax for keys (that would be understood by all
functions that take a key).

> On another note, I find it weird that we can bind keys to menu-items,
> but that is the only way to get at some functionality.  This should
> probably be fixed.

Probably.

> On a third note, why don't we just provide a better interface for
> creating menu items that is not based on pretending that a menu item
> like a key?  Do we need to leak that implementation detail for some
> didactic reason, or something?

easy-menu-define hides all this weirdness, so if we rewrote all the
menus to use that, then we could try not to leak it any more.  But we
can't really remove this old way, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Andreas Schwab]

On Okt 14 2021, Lars Ingebrigtsen wrote:

> So the [f] syntax would be ambiguous.

[t] also means default binding.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> [t] also means default binding.

Ah, yeah.  So it's definitely a no go.

A variant would be possible -- I mean, by putting in some more syntax.
Like:

[:C-c C-c]
[:t]
[:M-<down>]
[-C-c C-c]
[{C-c C-c}]

But...  I'm not sure that's super attractive.  It's too much of a trick,
too.

["C-c C-c"]

The string-in-a-vector syntax is the easiest to handle -- it's very
regular, well-understood syntax that doesn't look magical.

And since it's totally non-ambiguous, and we could make it error out on
everything that's not valid.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]


>
> ["C-c C-c"]
>
> The string-in-a-vector syntax is the easiest to handle -- it's very 
> regular, well-understood syntax that doesn't look magical.
>
> And since it's totally non-ambiguous, and we could make it error out on 
> everything that's not valid.
>

It's still not clear to me why it's necessary to introduce a fifth syntax 
for key bindings.

Here's a more detailed patch, which isn't a proof of concept anymore.  It 
performs a check of the input string, and if it happens to have the 
"strict" kbd syntax (the one that's used everywhere), converts it with 
kbd.  It passes make check, and does not seem to pose problems elsewhere.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=Make-it-possible-to-use-the-kbd-key-binding-syntax-i.patch, Size: 5368 bytes --]

From 39cd91751cd2b7c2eac63f556d6d3dea6b8ab655 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Sat, 16 Oct 2021 16:47:47 +0000
Subject: [PATCH] Make it possible to use the kbd key binding syntax in more
 places.

* src/keymap.c (is_kbd_key, maybe_convert_kbd_key): New functions.
(Fdefine_key, Flookup_key, Fkey_binding, Fminor_mode_key_binding):
Use the new functions, and document the change.
(syms_of_keymap): Add symbol.
---
 src/keymap.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/src/keymap.c b/src/keymap.c
index be45d2be1e..4b1054079b 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1026,6 +1026,86 @@ DEFUN ("copy-keymap", Fcopy_keymap, Scopy_keymap, 1, 1, 0,
 
 /* GC is possible in this function if it autoloads a keymap.  */
 
+static bool
+is_kbd_key (char *key)
+{
+  bool mod[6];
+  bool space = false;
+  if (strlen (key) < 2)
+    return false;
+  while (*key)
+    {
+      if (space && *key != ' ')
+	return false;
+      if (*key == ' ')
+	{
+	  if (!space || !*(key + 1))
+	    return false;
+	  space = false;
+	  key++;
+	  continue;
+	}
+      mod[0] = mod[1] = mod[2] = mod[3] = mod[4] = mod[5] = false;
+      while (((*key == 'A' && !mod[0] && (mod[0] = true)) ||
+	      (*key == 'C' && !mod[1] && (mod[1] = true)) ||
+	      (*key == 'H' && !mod[2] && (mod[2] = true)) ||
+	      (*key == 'M' && !mod[3] && (mod[3] = true)) ||
+	      (*key == 's' && !mod[4] && (mod[4] = true)) ||
+	      (*key == 'S' && !mod[5] && (mod[5] = true))) &&
+	     *(key + 1) == '-')
+	key += 2;
+      if (!strncmp (key, "NUL", 3) || !strncmp (key, "RET", 3) ||
+	  !strncmp (key, "LFD", 3) || !strncmp (key, "TAB", 3) ||
+	  !strncmp (key, "ESC", 3) || !strncmp (key, "SPC", 3) ||
+	  !strncmp (key, "DEL", 3))
+	{
+	  space = true;
+	  key += 3;
+	  continue;
+	}
+      if (*key == '<' &&
+	  ((*(key + 1) >= 'a' && *(key + 1) <= 'z') ||
+	   (*(key + 1) >= 'A' && *(key + 1) <= 'Z')))
+	{
+	  key++;
+	  while (*key && *key != '>')
+	    {
+	      if (!((*key >= 'a' && *key <= 'z') ||
+		    (*key >= 'A' && *key <= 'Z') ||
+		    (*key >= '0' && *key <= '9') ||
+		    *key == '-' || *key == '_'))
+		return false;
+	      key++;
+	    }
+	  if (*key != '>')
+	    return false;
+	  space = true;
+	  key++;
+	  continue;
+	}
+      if (*key >= '!' && *key <= '~')
+	{
+	  space = true;
+	  key++;
+	  continue;
+	}
+      return false;
+    }
+  return true;
+}
+
+static Lisp_Object
+maybe_convert_kbd_key (Lisp_Object key)
+{
+  Lisp_Object kbd_key;
+  if (STRINGP (key) &&
+      is_kbd_key (SSDATA (key)) &&
+      !NILP (Ffboundp (Qkbd)) &&
+      !NILP ((kbd_key = safe_call1 (Qkbd, key))))
+    key = kbd_key;
+  return key;
+}
+
 DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
        doc: /* In KEYMAP, define key sequence KEY as DEF.
 KEYMAP is a keymap.
@@ -1037,6 +1117,8 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
  [remap COMMAND] remaps any key binding for COMMAND.
  [t] creates a default definition, which applies to any event with no
     other definition in KEYMAP.
+When KEY is a string in the format returned by commands such as `C-h k'
+\(`describe-key'), it is first processed by `kbd', which see.
 
 DEF is anything that can be a key's definition:
  nil (means key is undefined in this keymap),
@@ -1059,6 +1141,8 @@ DEFUN ("define-key", Fdefine_key, Sdefine_key, 3, 3, 0,
 {
   bool metized = false;
 
+  key = maybe_convert_kbd_key (key);
+
   keymap = get_keymap (keymap, 1, 1);
 
   ptrdiff_t length = CHECK_VECTOR_OR_STRING (key);
@@ -1204,6 +1288,8 @@ DEFUN ("lookup-key", Flookup_key, Slookup_key, 2, 3, 0,
 {
   bool t_ok = !NILP (accept_default);
 
+  key = maybe_convert_kbd_key (key);
+
   if (!CONSP (keymap) && !NILP (keymap))
     keymap = get_keymap (keymap, true, true);
 
@@ -1577,6 +1663,8 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 DEFUN ("key-binding", Fkey_binding, Skey_binding, 1, 4, 0,
        doc: /* Return the binding for command KEY in current keymaps.
 KEY is a string or vector, a sequence of keystrokes.
+When KEY is a string in the format returned by commands such as `C-h k'
+\(`describe-key'), it is first processed by `kbd', which see.
 The binding is probably a symbol with a function definition.
 
 Normally, `key-binding' ignores bindings for t, which act as default
@@ -1602,6 +1690,8 @@ DEFUN ("key-binding", Fkey_binding, Skey_binding, 1, 4, 0,
   */)
   (Lisp_Object key, Lisp_Object accept_default, Lisp_Object no_remap, Lisp_Object position)
 {
+  key = maybe_convert_kbd_key (key);
+
   if (NILP (position) && VECTORP (key))
     {
       if (ASIZE (key) == 0)
@@ -1661,6 +1751,8 @@ DEFUN ("minor-mode-key-binding", Fminor_mode_key_binding, Sminor_mode_key_bindin
   int nmaps = current_minor_maps (&modes, &maps);
   Lisp_Object binding = Qnil;
 
+  key = maybe_convert_kbd_key (key);
+
   int j;
   for (int i = j = 0; i < nmaps; i++)
     if (!NILP (maps[i])
@@ -3261,4 +3353,6 @@ syms_of_keymap (void)
   defsubr (&Stext_char_description);
   defsubr (&Swhere_is_internal);
   defsubr (&Sdescribe_buffer_bindings);
+
+  DEFSYM (Qkbd, "kbd");
 }
-- 
2.33.0

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Stefan Monnier]

> (define-key map [tab] 'todo-next-button)
>
> Hm, the kbd syntax would be
>
> (define-key map [TAB] 'todo-next-button)
>
> but I guess it's fine...

No, the `kbd` syntax for `tab` is "<tab>".

> (define-key function-key-map [C-delete] [?\M-d])
> That's C-<delete> in kbd syntax -- I guess it's fine if we accept both,
> but then we lose the opportunity to be stricter with the syntax.

I guess we could also accept `C-<delete>`, but I think it would be
better to catch it and signal an error.

> Oh, yeah, I had totally forgotten that this is how menus are defined.
> To it's ambiguous here -- the thing in [] could be anything, including
> [s], which kdb would interpret as the key "s".

This area of Emacs is tricky enough that we may encounter surprises, but
I think using [?s] for such a menu entry "key binding" would work just
fine, currently.

> This form is limited to menu items, though, so perhaps it could be made
> to work (i.e., if the DEF is a menu item, then we have different logic).

I'd rather not go there.


        Stefan

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (define-key map [TAB] 'todo-next-button)
>>
>> but I guess it's fine...
>
> No, the `kbd` syntax for `tab` is "<tab>".

Yeah, I meant we could probably work around that for these keys and
allow both syntaxes.

> I guess we could also accept `C-<delete>`, but I think it would be
> better to catch it and signal an error.

Yup.

>> Oh, yeah, I had totally forgotten that this is how menus are defined.
>> To it's ambiguous here -- the thing in [] could be anything, including
>> [s], which kdb would interpret as the key "s".
>
> This area of Emacs is tricky enough that we may encounter surprises, but
> I think using [?s] for such a menu entry "key binding" would work just
> fine, currently.

Hm...  I have admittedly not tested this, but I thought it might collide
with the way things like facemenu defines its keymap, with the `cons'
definition.

(local-set-key "\C-c\C-c"
	       (define-keymap
		 :name "Zot"
		 [?k] '("foo" . ignore)
		 [?z] '("bar" . ignore)))

Yup, that binds `C-c C-c k'.

>> This form is limited to menu items, though, so perhaps it could be made
>> to work (i.e., if the DEF is a menu item, then we have different logic).
>
> I'd rather not go there.

Me neither, since there's also

    (define-key map [sepmv] '("--"))

For one bright, shiny moment I thought we could look into the keymap and
see whether the keymap "is a menu", but the only hint that they are is
that they have a name.  And as we saw in the code snippet, that's not
exclusive to actual menus, but also to those oddball
prompt-in-the-minibuffer "menus".

So I think that the [C-c C-k] syntax doesn't quite work unambiguously.

Unless I'm missing something, which I might well be.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>
> However, that style as implemented by 'kbd' is not without its problems. 
> It is too allowing in some cases where it would be better to be more 
> strict:
>

Yes, one possible improvement would have been to implement a stricter 
"kbd" to use in this case.

>
> Stefan Monnier says that we should also be able to say things like 
> [(control x)], and I have no objections to that.
>

This should not change and does not change with the proposal.

>> Frankly, I don't see how this minor, and as I've said almost 
>> theoretical problem, should force us to create yet another syntax and 
>> yet another set of key binding functions.
>
> Ambiguity is not a good property to have in our most fundamental 
> interfaces, IMO.
>

The proposed syntax is not ambiguous AFAICS.  It's true that there's one 
corner case, which could potentially affect a handful of users, who want 
to bind the upper case letters C, S, M and H, or the lower case letter s, 
followed by a dash.  IMO sacrificing a simple solution for that corner 
case is not reasonable.

>
> I think we should not try to retro-fit any DWIM stuff on the old one, as 
> that will lead to various problems.  It would be better to provide a new 
> one and promote that as a replacement.
>

The existing key binding functions have existed for several decades, so it 
would take several decades to replace them other ones.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Andreas Schwab]

On Okt 14 2021, Gregory Heytings wrote:

> The proposed syntax is not ambiguous AFAICS.  It's true that there's one
> corner case, which could potentially affect a handful of users, who want 
> to bind the upper case letters C, S, M and H, or the lower case letter s,
> followed by a dash.  IMO sacrificing a simple solution for that corner 
> case is not reasonable.

lisp/calc/calc-ext.el:  (define-key calc-mode-map "s-" 'calc-store-minus)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Gregory Heytings]

>
> lisp/calc/calc-ext.el:  (define-key calc-mode-map "s-" 'calc-store-minus)
>

lisp/calc/calc-ext.el:  (define-key calc-mode-map [(s) (-)] 'calc-store-minus)

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No need to apologize.  But what do you (and others) think of the idea? 
  > It would be a (IMO elegant) way to "phase out strings (where every char 
  > represents an event)".

I think we should deprecate that method of specifying keys for binding
and (over time) convert all its uses to something nicer.

But we should not delete the support for it -- not ever.
It would cause gratuitous trouble to break all old programs like that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Over time, and if we don't take action, this risks leading to a
  > proliferation in various conflicting and incompatible styles, that all
  > depend on this or that third-party package.  Meanwhile, Emacs yet again
  > looks archaic and too stuck in our old ways.

We must not let our actions be driven by "how it might look" to
others.  To grant weight to that sort of thinking makes one
vulnerable.  Especially we must never make changes so as not to look
old-fashioned.  Let's take care not to think of any questions that
way!

We should do what is right.

"Right" in software design is partly a matter of what makes usage
convenient, but that is not the only factor.  Not even the only
technical factor.

Nonetheless, maybe we should fully adopt a cleaner interface for
specifying a key to bind.

The existing one has no particular advantage except keeping changes
superficial over the years.  It would have caused problems to change
that interface over and over in complex ways.

But I think we have extended keys as much as we ever will need to,
which means that now we could adopt a new interface once and forever
-- one we won't need to change again later.

It is useful that people have experimented with other interfaces.
That provides ideas we could look at and draw on in choosing a new
spec.

But let's try to make the new interface simple.

It might be good always to use a vector for a key sequence.  Maybe
`kbd' could accept a vector and process each element.  If an element
is a symbol, it could pass that symbol through.

If an element is a string, it could process that string as it does
now.

It would then splice the elements of the resulting string
into the vector.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Juri Linkov]

> It's confusing because it'd be a different syntax for define-key and
> define-keymap.
>
> If we were redesigning all the Emacs keymap functions from scratch, I'd
> go with the `kbd' syntax for keys, but unfortunately we aren't.

We could add a new keyword to define-keymap, e.g.

  :kbd t

then all strings will use the `kbd' syntax.
Or to use the `kbd' syntax by default, then

  :kbd nil

will disable it.

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> We could add a new keyword to define-keymap, e.g.
>
>   :kbd t
>
> then all strings will use the `kbd' syntax.
> Or to use the `kbd' syntax by default, then
>
>   :kbd nil
>
> will disable it.

That's possible.  We'd also need a shorter version of `key-description'
for those that can't remember the kbd syntax in a :kbd t map (so that
people have the same flexibility as today).  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 12 Oct 2021 05:47:46 -0700
> 
> larsi@gnus.org (Lars Ingebrigtsen) writes:
> 
> > branch: master
> > commit 859190f03e87601324d394178d90e6dea5cd4002
> > Author: Lars Ingebrigtsen <larsi@gnus.org>
> > Commit: Lars Ingebrigtsen <larsi@gnus.org>
> >
> >     Convert some keymaps to defvar-keymap
> 
> Any chance we could make these new macros use `kbd' by default?

Careful: use of kbd in code that's preloaded fails bootstrap!

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Any chance we could make these new macros use `kbd' by default?

  > Careful: use of kbd in code that's preloaded fails bootstrap!

It's probably not hard to arrange to give a compiler warning for use
of `kbd' in a file that's preloaded.  There could be a file local
variable to enable the warning, and a compilation property to
give the warning.

This might save enough trouble in false starts
to be worth the trouble of implementing this.

Or perhaps we should preload `kbd' so it can be used everywhere.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 859190f 2/3: Convert some keymaps to defvar-keymap

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org
> Date: Wed, 13 Oct 2021 18:36:59 -0400
> 
>   > > Any chance we could make these new macros use `kbd' by default?
> 
>   > Careful: use of kbd in code that's preloaded fails bootstrap!
> 
> It's probably not hard to arrange to give a compiler warning for use
> of `kbd' in a file that's preloaded.

That's too late: the first stage of bootstrap loads the preloaded
files as *.el.

Besides, relying on byte-compiler warnings for this stuff is not a
very efficient idea: since the bootstrap takes several minutes on even
a fast machine, people usually turn their attention to other places
and tasks while the build runs, and so will miss the warning.