bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Arash Esbati]

Hi all,

I tried to switch from `global-set-key' to `keymap-global-set' and this
is my first observation: I can't use shorthand syntax.  To reproduce:

1. emacs -Q
2. In scratch, eval (key-valid-p "C-TAB") => t
3. In scratch, eval (keymap-global-set "C-TAB" #'other-window)
4. Try 'C-h k Ctrl-Tab' => C-<tab> is undefined
5. In scratch, eval (keymap-global-set "C-<tab>" #'other-window)
6. 'C-h k Ctrl-Tab' returns the expected result.

Am I missing something about shorthands?  Reading the docstring of
`key-valid-p', I thought the item 3. above should also work.  This is
Emacs from master 22d3f0e95a.

Best, Arash

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> I tried to switch from `global-set-key' to `keymap-global-set' and this
> is my first observation: I can't use shorthand syntax.  To reproduce:
>
> 1. emacs -Q
> 2. In scratch, eval (key-valid-p "C-TAB") => t
> 3. In scratch, eval (keymap-global-set "C-TAB" #'other-window)
> 4. Try 'C-h k Ctrl-Tab' => C-<tab> is undefined
> 5. In scratch, eval (keymap-global-set "C-<tab>" #'other-window)
> 6. 'C-h k Ctrl-Tab' returns the expected result.
>
> Am I missing something about shorthands?  Reading the docstring of
> `key-valid-p', I thought the item 3. above should also work.

TAB is a complicated issue in Emacs, unfortunately.

"C-TAB" is just a different way to write "C-i", because TAB and C-i are
the same in most terminals.

If you want to bind the C-<tab> key stroke, you have to specify it as
such.  (And it won't work in most terminals, only in GUI Emacs.)

(key-valid-p "C-TAB") could signal an error to help lessen the
confusion, I guess?  (And C-RET and C-LFD.)  Anybody got an opinion
here?

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

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Eli Zaretskii]

> Cc: 55842@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 09 Jun 2022 15:35:02 +0200
> 
> > 1. emacs -Q
> > 2. In scratch, eval (key-valid-p "C-TAB") => t
> > 3. In scratch, eval (keymap-global-set "C-TAB" #'other-window)
> > 4. Try 'C-h k Ctrl-Tab' => C-<tab> is undefined
> > 5. In scratch, eval (keymap-global-set "C-<tab>" #'other-window)
> > 6. 'C-h k Ctrl-Tab' returns the expected result.
> >
> > Am I missing something about shorthands?  Reading the docstring of
> > `key-valid-p', I thought the item 3. above should also work.
> 
> TAB is a complicated issue in Emacs, unfortunately.
> 
> "C-TAB" is just a different way to write "C-i", because TAB and C-i are
> the same in most terminals.
> 
> If you want to bind the C-<tab> key stroke, you have to specify it as
> such.  (And it won't work in most terminals, only in GUI Emacs.)
> 
> (key-valid-p "C-TAB") could signal an error to help lessen the
> confusion, I guess?  (And C-RET and C-LFD.)  Anybody got an opinion
> here?

Without thinking about this too much, my opinion is that if the new
APIs are to be the replacement for the obsolete ones, they had better
supported the same syntax, because I don't believe there's a single
Emacs user out there who doesn't have some key bindings in their init
files.  If the syntax is incompatible, how can we ever convince the
majority to switch?

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Without thinking about this too much, my opinion is that if the new
> APIs are to be the replacement for the obsolete ones, they had better
> supported the same syntax, because I don't believe there's a single
> Emacs user out there who doesn't have some key bindings in their init
> files.  If the syntax is incompatible, how can we ever convince the
> majority to switch?

I'm not sure what you mean here.  People that previously said
(local-set-key "\C-\M-i" ... ) can say (keymap-local-set "C-M-i" ...)
just fine.

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

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure what you mean here.  People that previously said
> (local-set-key "\C-\M-i" ... ) can say (keymap-local-set "C-M-i" ...)
> just fine.

Or do you mean C-TAB?  I misspoke -- that's not the same as C-i, it's
(key-parse "C-TAB") => [67108873] (now and before), which is not the
same as (key-parse "C-<tab>") => [C-tab], which was my point.

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

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: arash@gnu.org,  55842@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 18:37:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Without thinking about this too much, my opinion is that if the new
> > APIs are to be the replacement for the obsolete ones, they had better
> > supported the same syntax, because I don't believe there's a single
> > Emacs user out there who doesn't have some key bindings in their init
> > files.  If the syntax is incompatible, how can we ever convince the
> > majority to switch?
> 
> I'm not sure what you mean here.  People that previously said
> (local-set-key "\C-\M-i" ... ) can say (keymap-local-set "C-M-i" ...)
> just fine.

My point is that (keymap-local-set "\C-\M-i" ...) signals an error,
and a weird one at that.  I hoped that we could make the APIs fully
compatible.

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> My point is that (keymap-local-set "\C-\M-i" ...) signals an error,
> and a weird one at that.  I hoped that we could make the APIs fully
> compatible.

The aim with these new functions were to settle on a single syntax for
keys, and the syntax we settled on was the `kbd' one.  You can't
do (keymap-local-set "\C-\M-i" ...) or (keymap-local-set [?\C-\M-i] .. )
or (keymap-local-set [(control meta i)] ...) either -- that was the
whole point of the exercise.

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

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: arash@gnu.org,  55842@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 19:14:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My point is that (keymap-local-set "\C-\M-i" ...) signals an error,
> > and a weird one at that.  I hoped that we could make the APIs fully
> > compatible.
> 
> The aim with these new functions were to settle on a single syntax for
> keys, and the syntax we settled on was the `kbd' one.  You can't
> do (keymap-local-set "\C-\M-i" ...) or (keymap-local-set [?\C-\M-i] .. )
> or (keymap-local-set [(control meta i)] ...) either -- that was the
> whole point of the exercise.

Then I wish us good luck convincing users to switch.

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If you want to bind the C-<tab> key stroke, you have to specify it as
> such.

Thanks for your response.  This is what I had, so I just removed the
(kbd ...) around it.

> (key-valid-p "C-TAB") could signal an error to help lessen the
> confusion, I guess?

Wouldn't it be enough to return nil?

> (And C-RET and C-LFD.)  Anybody got an opinion here?

I think it should suffice to make `key-valid-p' return nil and adjust
its docstring to say there are 3 exceptions to the rule.

Best, Arash

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

>> (key-valid-p "C-TAB") could signal an error to help lessen the
>> confusion, I guess?
>
> Wouldn't it be enough to return nil?

As I said in a later post -- I was the one that was confused here.
"C-TAB" is valid (and is a different key than "C-i", "TAB" and
"C-<tab>"), so this is working as designed, even if the design is pretty
confusing (for historical reasons, mostly).

And this hasn't changed with the new keymap-* functions -- they just
reproduce the previous behaviour here, so I guess there's nothing here
to be done, and I'm therefore closing this bug report.

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

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I said in a later post -- I was the one that was confused here.

You were not alone there ;-)

> "C-TAB" is valid (and is a different key than "C-i", "TAB" and
> "C-<tab>"), so this is working as designed, even if the design is
> pretty confusing (for historical reasons, mostly).

I should have read that message more carefully.  Thanks for looking into
this.

Best, Arash

bug#55842: 29.0.50; Using shorthand syntax in keymap-global-set

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

  > > The aim with these new functions were to settle on a single syntax for
  > > keys, and the syntax we settled on was the `kbd' one.  You can't
  > > do (keymap-local-set "\C-\M-i" ...) or (keymap-local-set [?\C-\M-i] .. )
  > > or (keymap-local-set [(control meta i)] ...) either -- that was the
  > > whole point of the exercise.

  > Then I wish us good luck convincing users to switch.

Even if we never convince _all users_ to switch, if most packages
use the new syntax, that will be an improvement in clarity.

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