[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange behavior of C-u in the presence of sit-for in p-c-h
From: |
Stefan Monnier |
Subject: |
Re: Strange behavior of C-u in the presence of sit-for in p-c-h |
Date: |
Tue, 17 Oct 2006 21:57:17 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
> This normally works ok. However, suppose the call to
> read_key_sequence in the command loop takes its input from
> unread-command-events. (This happens if the input came during a
> sit-for in post-command-hook, as in Stefan's original example, or
> directly as in the example above.) This kind of "reread input" is
> explicitly *not* added to this_command_keys. The rationale for this
> is not clear to me, but there may be a good reason since the code
> explicitly checks for this; see keyboard.c:789. Then
> `universal-argument-other-key' can't see that input.
> OTOH, I don't see a safe way of fixing this. Any suggestions?
The check on line 3262 seems odd. If we trace it back it was introduced in
revision 1.489 in the following form:
if (this_command_key_count == 0 || ! reread)
the log comment doesn't say much useful:
(read_char): Call the input method if appropriate.
Change logic for distinguishing rereads from new events;
use local var `reread'. Take events from
Vunread_input_method_events and Vunread_post_input_method_events.
I'm not sure exactly what this was trying to avoid, but the test looks odd.
Maybe the "!reread" could make some sense, but the
"this_command_key_count==0" looks positively odd since it may end up
recording the first (and only the first) of a sequence of keys.
Maybe the problem is that `this-command-keys' has several potential uses and
they are incompatible: in one case one wants this-command-keys to list the
keys the user has typed (independently from whether or not some of those
keys were later read&unread&reread&reunread&rereread), whereas in the other
one wants the exact key-sequence which triggered this command, so we can
push it back on unread-command-events to force re-interpretation of
those keys.
Stefan
- Strange behavior of C-u in the presence of sit-for in p-c-h, Stefan Monnier, 2006/10/14
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Richard Stallman, 2006/10/16
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Stefan Monnier, 2006/10/16
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Richard Stallman, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Stefan Monnier, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h,
Stefan Monnier <=
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/17
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Stefan Monnier, 2006/10/18
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/18
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Stefan Monnier, 2006/10/18
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Richard Stallman, 2006/10/19
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Richard Stallman, 2006/10/19
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/19
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Johan Bockgård, 2006/10/19
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Richard Stallman, 2006/10/18
- Re: Strange behavior of C-u in the presence of sit-for in p-c-h, Chong Yidong, 2006/10/18