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.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Holman <john.g.holman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; failure binding keys to certain unicode characters
Date: Sat, 7 Jun 2025 12:46:56 +0100

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

Message #8 received at 78714 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Holman <john.g.holman <at> gmail.com>
Cc: 78714 <at> debbugs.gnu.org
Subject: Re: bug#78714: 30.1;
 failure binding keys to certain unicode characters
Date: Sat, 07 Jun 2025 15:05:55 +0300

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

Message #11 received at 78714 <at> debbugs.gnu.org (full text, mbox):

From: John Holman <john.g.holman <at> gmail.com>
To: 78714 <at> debbugs.gnu.org
Date: Sat, 7 Jun 2025 13:42:39 +0100

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

Message #14 received at 78714 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: John Holman <john.g.holman <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78714 <at> debbugs.gnu.org
Subject: Re: bug#78714: 30.1;
 failure binding keys to certain unicode characters
Date: Sat, 07 Jun 2025 15:45:04 +0300

[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 #17 received at 78714 <at> debbugs.gnu.org (full text, mbox):

From: John Holman <john.g.holman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78714 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#78714: 30.1;
 failure binding keys to certain unicode characters
Date: Sat, 7 Jun 2025 13:46:22 +0100

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

Message #20 received at 78714 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: John Holman <john.g.holman <at> gmail.com>
Cc: 78714 <at> debbugs.gnu.org
Subject: Re: bug#78714: 30.1; failure binding keys to certain unicode
 characters
Date: Sat, 07 Jun 2025 16:29:27 +0200

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

Previous Next

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