GNU bug report logs - #73764
format-kbd-macro returns a key name that keymap-lookup doesn't recognize

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: rpluim <at> gmail.com
Cc: 73764 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca, eduardoochs <at> gmail.com
Subject: bug#73764: format-kbd-macro returns a key name that keymap-lookup doesn't recognize
Date: Mon, 14 Oct 2024 19:25:33 +0300

> Cc: 73764 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, monnier <at> iro.umontreal.ca,
>  eduardoochs <at> gmail.com
> Date: Mon, 14 Oct 2024 18:54:27 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Robert Pluim <rpluim <at> gmail.com>
> > Cc: Andreas Schwab <schwab <at> linux-m68k.org>,  73764 <at> debbugs.gnu.org,
> >   monnier <at> iro.umontreal.ca,  eduardoochs <at> gmail.com
> > Date: Mon, 14 Oct 2024 17:06:05 +0200
> > 
> > So if format-kbd-macro generates something with 'C-' in the "wrong"
> > place, whatʼs to stop us re-ordering the modifiers as a
> > post-processing step (inside `format-kbd-macro')?
> 
> If that's the only case where we put C- in the wrong place, then
> nothing stops us.  Is it?

In any case, there's the more general issue at hand here:
keymap--check is (at least in this case) unnecessarily restrictive:
where key-parse will gladly accept and correctly process a key whose
modifiers are in any order, keymap--check insist on the canonical
order.  I'm not sure I like this, at least in non-interactive
functions.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.