From: Eli Zaretskii <eliz@gnu.org>
To: Jan Tatarik <jan.tatarik@gmail.com>
Cc: 20223@debbugs.gnu.org
Subject: bug#20223: 25.0.50; key-chord.el crashes Emacs
Date: Mon, 30 Mar 2015 18:04:26 +0300 [thread overview]
Message-ID: <83y4mey1ad.fsf@gnu.org> (raw)
In-Reply-To: <874mp43ywp.fsf@xing.com>
> From: Jan Tatarik <jan.tatarik@gmail.com>
> Date: Sun, 29 Mar 2015 12:01:42 +0200
>
> This can be reproduced from emacs -Q, with just key-chord.el
> loaded. Happens with the latest key-chord available from MELPA
> (key-chord-20140929.2246.el). Tried with current emacs master.
>
> (package-install-file "/PATH/TO/key-chord.el")
> (key-chord-define-global "vv" ctl-x-r-map)
> (key-chord-mode 1)
>
> Pressing [vv b] will execute bookmark-jump, as expected.
>
> But pressing the key-chord with a key that is not defined in the target
> map will crash Emacs immediately. Try [vv q], for instance.
>
> Only the fact that matters is the key not defined in the map. The actual
> key-chord (tried vv, pf, others) nor the map affect the outcome.
This happens because key-chord triggers a situation where the value of
't' in the snippet below (from read_key_sequence) is not in sync with
the value of 'this_command_key_count':
/* Record what part of this_command_keys is the current key sequence. */
this_single_command_key_start = this_command_key_count - t;
If 't' is greater than this_command_key_count, then
this_single_command_key_start will be assigned a negative value. In
this scenario, the result is -2 (t is 4, while this_command_key_count
is 2). Then this-single-command-keys will produce a vector with bogus
elements. And when a key sequence is undefined, we invoke
'undefined', which does this:
(message "%s is undefined" (key-description (this-single-command-keys)))
So we are trying to display bogus data, with predictable results.
The same problem happens if you type "v v b", but we escape narrowly
because this key sequence is bound to a command, so we don't try to
access the result of this-single-command-keys.
I can fix this with the simple patch shown below. It looks like
papering over the problem, and perhaps it is. But I couldn't find any
obvious place where this_command_key_count should have been
incremented, but wasn't. We avoid incrementing it in this scenario
because the value of 'reread' variable is 'true', since we have events
in unread-post-input-method-events after invoking the "input-method"
provided by key-chord.
HTH
--- src/keyboard.c~ 2015-03-08 08:16:29 +0200
+++ src/keyboard.c 2015-03-29 15:45:46 +0300
@@ -9591,6 +9591,8 @@ read_key_sequence (Lisp_Object *keybuf,
/* Record what part of this_command_keys is the current key sequence. */
this_single_command_key_start = this_command_key_count - t;
+ if (this_single_command_key_start < 0)
+ this_single_command_key_start = 0;
/* Look for this sequence in input-decode-map.
Scan from indec.end until we find a bound suffix. */
next prev parent reply other threads:[~2015-03-30 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-29 10:01 bug#20223: 25.0.50; key-chord.el crashes Emacs Jan Tatarik
2015-03-30 15:04 ` Eli Zaretskii [this message]
2015-03-30 19:22 ` Jan Tatarik
2015-03-30 21:01 ` Stefan Monnier
2015-03-31 14:21 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y4mey1ad.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=20223@debbugs.gnu.org \
--cc=jan.tatarik@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.