GNU bug report logs -
#78714
30.1; failure binding keys to certain unicode characters
Previous Next
To reply to this bug, email your comments to 78714 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 11:48:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
John Holman <john.g.holman <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 07 Jun 2025 11:48:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
--text follows this line--
Attempting to bind unicode characters (e.g. \u111E) to keys in a minor mode
with syntax like
(define-key my-test-mode-map (kbd "c") "\u221E")
usually works. In this case, C-h k c shows
c runs the command #<string CB7> (found in my-test-mode-map), which is
a keyboard macro.
It is bound to c.
Macro: M-\20636
Keyboard macro.
However the same syntax fails for some characters (so far I've noticed this
for \u00B0 to \u00B6 but there will be more) e.g
after (define-key my-test-mode-map (kbd "a") "\u00B2") C-h k shows
a runs the command #<string B6B> (found in my-test-mode-map), which is
a keyboard macro.
It is bound to a.
Macro: M-2
Keyboard macro.
and the effect of pressing "a" is to invoke command-digit-argument rather
than insert the required character
A workaround is to use a lambda expression to bypass whatever emacs is
doing when processing the unicode character, e.g.
(define-key my-test-mode-map (kbd "b") (lambda () (interactive) (insert
"\u00B2")))
and then this does insert the character (superscript 2) when "b" is pressed.
To replicate:
1. run emacs -Q
2. paste the following into the scratch buffer:
;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with ‘C-x C-f’ and enter text in its buffer.
(progn
;; 1. Explicitly create the keymap variable and initialize it.
(defvar my-test-mode-map (make-sparse-keymap)
"Keymap for `my-test-mode'.")
;; 2. Define the minor mode, telling it to use our explicitly created map.
(define-minor-mode my-test-mode
"A test minor mode."
:global t
:lighter " my-test"
:keymap my-test-mode-map
)
;; 3. Define keys on the explicitly created and linked map.
;; normal bind fails at least for characters in range \u00B0 to \u00B6, but
probably more, e.g. \u00B2
(define-key my-test-mode-map (kbd "a") "\u00B2")
;; workaround is to use a lambda
(define-key my-test-mode-map (kbd "b") (lambda () (interactive) (insert
"\u00B2")))
; normal bind does succeeds with other characters I've tried so far, e.g.
\u221E
(define-key my-test-mode-map (kbd "c") "\u221E")
;; 4. Enable the minor mode.
(my-test-mode 1)
)
===
This creates a new mode "my-test-mode" with the key maps and puts it into
effect. Then try pressing a, b and c.
(acknowledgements to assistance from gemini 2.5 on all this!)
In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.4061)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2
prefix=/g/rel/install/emacs-30.1'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: ENG
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)
Memory information:
((conses 16 51324 17148) (symbols 48 5411 0) (strings 32 15047 1817)
(string-bytes 1 418055) (vectors 16 8994)
(vector-slots 8 128954 11248) (floats 8 24 21) (intervals 56 313 5)
(buffers 992 10))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 12:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78714 <at> debbugs.gnu.org (full text, mbox):
> From: John Holman <john.g.holman <at> gmail.com>
> Date: Sat, 7 Jun 2025 12:46:56 +0100
>
> Attempting to bind unicode characters (e.g. \u111E) to keys in a minor mode with syntax like
> (define-key my-test-mode-map (kbd "c") "\u221E")
> usually works. In this case, C-h k c shows
>
> c runs the command #<string CB7> (found in my-test-mode-map), which is
> a keyboard macro.
> It is bound to c.
> Macro: M-\20636
> Keyboard macro.
>
> However the same syntax fails for some characters (so far I've noticed this for \u00B0 to \u00B6 but there
> will be more) e.g
> after (define-key my-test-mode-map (kbd "a") "\u00B2") C-h k shows
>
> a runs the command #<string B6B> (found in my-test-mode-map), which is
> a keyboard macro.
> It is bound to a.
> Macro: M-2
> Keyboard macro.
>
> and the effect of pressing "a" is to invoke command-digit-argument rather than insert the required character
It's a feature: #xB2 is #x32 with the high bit set, and the Meta bit
sets that bit. See current-input-mode.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 12:44:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Many thanks for the fast response. I do think that's a surprising feature
and that most users would expect "\u00B2" to be interpreted as a unicode
character especially given the \u representation, which I think is specific
to Unicode even if treated as just a variant numerical representation in
emacs. Would it perhaps make sense for emacs to take the \u format into
account when interpreting this?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 12:46:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 78714 <at> debbugs.gnu.org (full text, mbox):
[Please use Reply All" to reply, so as to keep the bug tracker CC'ed.]
> From: John Holman <john.g.holman <at> gmail.com>
> Date: Sat, 7 Jun 2025 13:38:49 +0100
>
> Many thanks for the fast response. I do think that's a surprising feature and that most users would expect
> "\u00B2" to be interpreted as a unicode character especially given the \u representation, which I think is
> specific to Unicode even if treated as just a variant numerical representation in emacs. Would it make sense
> for emacs to take the \u format into account when interpreting that string?
I don't think this is feasible, since by the time the character is
interpreted the information that it came from a "\uNNN" format is long
gone. But maybe Stefan (CC'ed) will have some ideas.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 12:47:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you.
On Sat, 7 Jun 2025 at 13:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
> [Please use Reply All" to reply, so as to keep the bug tracker CC'ed.]
>
> > From: John Holman <john.g.holman <at> gmail.com>
> > Date: Sat, 7 Jun 2025 13:38:49 +0100
> >
> > Many thanks for the fast response. I do think that's a surprising
> feature and that most users would expect
> > "\u00B2" to be interpreted as a unicode character especially given the
> \u representation, which I think is
> > specific to Unicode even if treated as just a variant numerical
> representation in emacs. Would it make sense
> > for emacs to take the \u format into account when interpreting that
> string?
>
> I don't think this is feasible, since by the time the character is
> interpreted the information that it came from a "\uNNN" format is long
> gone. But maybe Stefan (CC'ed) will have some ideas.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Sat, 07 Jun 2025 14:30:04 GMT)
Full text and
rfc822 format available.
Message #20 received at 78714 <at> debbugs.gnu.org (full text, mbox):
On Jun 07 2025, John Holman wrote:
> However the same syntax fails for some characters (so far I've noticed this
> for \u00B0 to \u00B6 but there will be more) e.g
> after (define-key my-test-mode-map (kbd "a") "\u00B2") C-h k shows
Use vector notation instead: [?\u0082]. Generally, use of strings to
represent key sequences should be avoided.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Mon, 09 Jun 2025 10:07:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Many thanks Andreas - that's certainly more concise than using a lambda.
I do think this is a trap for users who may expect that a key definition
that a single character string simply specifies the character to be
inserted when that key is pressed rather than a macro. Treating a string
with a single character as a character to insert rather than a
one-character macro might avoid that, or if that is awkward to implement or
otherwise undesirable an explicit warning in the documentation might help.
The documentation for define-key does say that a string is treated as a
keyboard macro, but the significance of that is easy to miss.
On Sat, 7 Jun 2025 at 15:29, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> On Jun 07 2025, John Holman wrote:
>
> > However the same syntax fails for some characters (so far I've noticed
> this
> > for \u00B0 to \u00B6 but there will be more) e.g
> > after (define-key my-test-mode-map (kbd "a") "\u00B2") C-h k shows
>
> Use vector notation instead: [?\u0082]. Generally, use of strings to
> represent key sequences should be avoided.
>
> --
> Andreas Schwab, schwab <at> linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Mon, 09 Jun 2025 11:49:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78714 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 9 Jun 2025 11:05:40 +0100, John Holman <john.g.holman <at> gmail.com> said:
John> Many thanks Andreas - that's certainly more concise than using a lambda.
John> I do think this is a trap for users who may expect that a key definition
John> that a single character string simply specifies the character to be
John> inserted when that key is pressed rather than a macro. Treating a string
John> with a single character as a character to insert rather than a
John> one-character macro might avoid that, or if that is awkward to implement or
John> otherwise undesirable an explicit warning in the documentation might help.
John> The documentation for define-key does say that a string is treated as a
John> keyboard macro, but the significance of that is easy to miss.
(info "(emacs) Init Rebinding") describes how to do this. The
docstring for `keymap-global-set' also mentions `key-description',
which avoids the need to manually write in vector notation, which I
guess we could add to `keymap-set' as well.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Mon, 09 Jun 2025 14:41:06 GMT)
Full text and
rfc822 format available.
Message #29 received at 78714 <at> debbugs.gnu.org (full text, mbox):
> Cc: 78714 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Mon, 09 Jun 2025 13:48:31 +0200
>
> >>>>> On Mon, 9 Jun 2025 11:05:40 +0100, John Holman <john.g.holman <at> gmail.com> said:
>
> John> Many thanks Andreas - that's certainly more concise than using a lambda.
> John> I do think this is a trap for users who may expect that a key definition
> John> that a single character string simply specifies the character to be
> John> inserted when that key is pressed rather than a macro. Treating a string
> John> with a single character as a character to insert rather than a
> John> one-character macro might avoid that, or if that is awkward to implement or
> John> otherwise undesirable an explicit warning in the documentation might help.
> John> The documentation for define-key does say that a string is treated as a
> John> keyboard macro, but the significance of that is easy to miss.
>
> (info "(emacs) Init Rebinding") describes how to do this. The
> docstring for `keymap-global-set' also mentions `key-description',
> which avoids the need to manually write in vector notation, which I
> guess we could add to `keymap-set' as well.
Feel free to add that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Mon, 09 Jun 2025 21:14:07 GMT)
Full text and
rfc822 format available.
Message #32 received at 78714 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Robert
I just tried using key-description, for example
(define-minor-mode math-typing-mode
"A minor mode for typing maths characters"
:init-value nil
:lighter " Math"
(let ((map (make-sparse-keymap)))
(if math-typing-mode
(progn
(define-key map (kbd "C-3") (key-description "\u00B3"))
(use-local-map map))
(use-local-map nil))))
but this produces the same result as
(define-key map (kbd "C-3") "\u00B3")
while
(define-key map (kbd "C-3") [?\u00B3]) or my original lambda works (inserts
the unicode character when you press C-3)
Probably I misunderstand what you are suggesting though?
On Mon, 9 Jun 2025 at 15:40, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: 78714 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
> > From: Robert Pluim <rpluim <at> gmail.com>
> > Date: Mon, 09 Jun 2025 13:48:31 +0200
> >
> > >>>>> On Mon, 9 Jun 2025 11:05:40 +0100, John Holman <
> john.g.holman <at> gmail.com> said:
> >
> > John> Many thanks Andreas - that's certainly more concise than using
> a lambda.
> > John> I do think this is a trap for users who may expect that a key
> definition
> > John> that a single character string simply specifies the character
> to be
> > John> inserted when that key is pressed rather than a macro.
> Treating a string
> > John> with a single character as a character to insert rather than a
> > John> one-character macro might avoid that, or if that is awkward to
> implement or
> > John> otherwise undesirable an explicit warning in the documentation
> might help.
> > John> The documentation for define-key does say that a string is
> treated as a
> > John> keyboard macro, but the significance of that is easy to miss.
> >
> > (info "(emacs) Init Rebinding") describes how to do this. The
> > docstring for `keymap-global-set' also mentions `key-description',
> > which avoids the need to manually write in vector notation, which I
> > guess we could add to `keymap-set' as well.
>
> Feel free to add that.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Tue, 10 Jun 2025 07:47:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 78714 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 9 Jun 2025 22:12:40 +0100, John Holman <john.g.holman <at> gmail.com> said:
John> Hi Robert
John> I just tried using key-description, for example
John> (define-minor-mode math-typing-mode
John> "A minor mode for typing maths characters"
John> :init-value nil
John> :lighter " Math"
John> (let ((map (make-sparse-keymap)))
John> (if math-typing-mode
John> (progn
John> (define-key map (kbd "C-3") (key-description "\u00B3"))
John> (use-local-map map))
John> (use-local-map nil))))
John> but this produces the same result as
John> (define-key map (kbd "C-3") "\u00B3")
John> while
John> (define-key map (kbd "C-3") [?\u00B3]) or my original lambda works (inserts
John> the unicode character when you press C-3)
John> Probably I misunderstand what you are suggesting though?
No, Iʼd forgotten about one of the corner cases of
`key-description'. `key-parse' would work here, but that probably has
other issues, so specifying the vector is your best bet.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78714
; Package
emacs
.
(Wed, 11 Jun 2025 13:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 78714 <at> debbugs.gnu.org (full text, mbox):
tags 78714 fixed
close 78714 30.2
quit
>>>>> On Mon, 09 Jun 2025 17:40:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> Cc: 78714 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Mon, 09 Jun 2025 13:48:31 +0200
>>
>> >>>>> On Mon, 9 Jun 2025 11:05:40 +0100, John Holman <john.g.holman <at> gmail.com> said:
>>
John> Many thanks Andreas - that's certainly more concise than using a lambda.
John> I do think this is a trap for users who may expect that a key definition
John> that a single character string simply specifies the character to be
John> inserted when that key is pressed rather than a macro. Treating a string
John> with a single character as a character to insert rather than a
John> one-character macro might avoid that, or if that is awkward to implement or
John> otherwise undesirable an explicit warning in the documentation might help.
John> The documentation for define-key does say that a string is treated as a
John> keyboard macro, but the significance of that is easy to miss.
>>
>> (info "(emacs) Init Rebinding") describes how to do this. The
>> docstring for `keymap-global-set' also mentions `key-description',
>> which avoids the need to manually write in vector notation, which I
>> guess we could add to `keymap-set' as well.
Eli> Feel free to add that.
Done
Robert
--
Pushed to emacs-30.
1bed2949583 2025-06-11T15:34:10+02:00 "* lisp/keymap.el (keymap-set): Refer to 'key-description'. (Bug#78714)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1bed29495836dab96fe642dbd6f4c1625c50b12a
Added tag(s) fixed.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 11 Jun 2025 13:41:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 30.2, send any further explanations to
78714 <at> debbugs.gnu.org and John Holman <john.g.holman <at> gmail.com>
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 11 Jun 2025 13:41:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.