diff options
| author | Tim Ruffing <crypto@timruffing.de> | 2023-12-27 14:32:09 +0100 |
|---|---|---|
| committer | Stefan Monnier <monnier@iro.umontreal.ca> | 2024-03-10 10:40:13 -0400 |
| commit | 6f46dd516b84ad7d59b49c2e9e3fc1a2d4ef4d1c (patch) | |
| tree | 4075841773bcb6992af91b1ec81b21d6c0b96f9e /lisp/emacs-lisp/bytecomp.el | |
| parent | d6f326452ecc761498d627a365c8014a467812eb (diff) | |
| download | emacs-6f46dd516b84ad7d59b49c2e9e3fc1a2d4ef4d1c.tar.gz emacs-6f46dd516b84ad7d59b49c2e9e3fc1a2d4ef4d1c.tar.bz2 emacs-6f46dd516b84ad7d59b49c2e9e3fc1a2d4ef4d1c.zip | |
Continue reading in 'read-event' etc. at the end of a keyboard macro
This fixes a bug that could make 'read-event', 'read-char', and
'read-char-exclusive' erroneously return -1, an internal magic return
value of 'read_char' leaked from C to lisp. Instead of returning -1, the
aforementioned lisp functions now transparently continue reading
available input (e.g., from the keyboard) when reaching the end of a
keyboard macro.
* src/keyboard.c (read_char, read_key_sequence): Move handling
of the end of a keyboard macro from 'read_char' to its caller
'read_key_sequence', which is the only caller that can
meaningfully deal with this case.
* src/macros.c (Fexecute_kbd_macro): Document how the end of keyboard
macro is processed.
* etc/NEWS: Announce this change.
Diffstat (limited to 'lisp/emacs-lisp/bytecomp.el')
0 files changed, 0 insertions, 0 deletions