GNU bug report logs -
#33749
26.1; input-decode-map to empty vector should preserve echo area
Previous Next
Full log
View this message in rfc822 format
On Thu, Dec 20, 2018 at 1:05 AM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > The call sequence that causes the echo to be cleared looks like this:
> >
> > command_loop_1 (in keyboard.c)
> > read_key_sequence
> > read_char
> > redisplay
> >
> > and much of the read_char and read_key_sequence mechanics maintain
> > echoing of the current prefix sequence.
>
> Have you been able to track down the precise call to (one of the C entry
> point of) `message` which causes the echo area to be cleared in
> your case?
Ah, of course, ‘redisplay’ clears the echo area visually, but it is
only enacting the state set by some previous call to ‘message’ or its
subcases.
There are many of these, that I considered it impractical to attempt
to prevent them all from happening.
* In ‘read_char’ around keyboard.c:2948:
/* Now wipe the echo area, except for help events which do their
own stuff with the echo area. */
if (!CONSP (c)
|| (!(EQ (Qhelp_echo, XCAR (c)))
&& !(EQ (Qswitch_frame, XCAR (c)))
/* Don't wipe echo area for select window events: These might
get delayed via `mouse-autoselect-window' (Bug#11304). */
&& !(EQ (Qselect_window, XCAR (c)))))
{
if (!NILP (echo_area_buffer[0]))
{
safe_run_hooks (Qecho_area_clear_hook);
→ clear_message (1, 0);
}
}
* In ‘read_key_sequence’ around keyboard.c:8981:
/* These are no-ops the first time through, but if we restart, they
revert the echo area and this_command_keys to their original state. */
this_command_key_count = keys_start;
if (INTERACTIVE && t < mock_input)
→ echo_truncate (echo_start);
and keyboard.c:9056:
replay_key:
/* These are no-ops, unless we throw away a keystroke below and
jumped back up to replay_key; in that case, these restore the
variables to their original state, allowing us to replay the
loop. */
if (INTERACTIVE && t < mock_input)
→ echo_truncate (echo_local_start);
this_command_key_count = keys_local_start;
> input-decode-map doesn't only apply to the beginning of a key-sequence,
> but also in the middle (e.g. in your case, when you do `C-x h` the
> input-decode-map likely applies to the "release control modifier" event
> that occurs between `C-x` and `h`).
>
> Returning -1 after `C-x` and before we got to read `h` wouldn't
> be right.
Yes, and the patch is written to only return -1 if the whole sequence
from the very beginning (i.e. start of read-key-sequence) is zeroed
out. Otherwise, after the re-reading, there is still a current prefix
and it is echoed as usual:
$ ./emacs -Q
(setq input-decode-preserve-echo 1)
→ 1
(define-key input-decode-map (kbd "<f5> <f5>") [])
→ []
<f5>
→ f5-
<f5>
→ []
ESC
→ ESC-
<f5>
→ ESC f5-
<f5>
→ ESC-
> Also, who/where do you intend to set input-decode-preserve-echo?
My current plan is:
* term/xterm-kitty.el will define a (customizable?) user variable
kitty-use-full-keyboard, boolean, default nil.
* If it is nil, ‘terminal-init-xterm-kitty’ will call
(terminal-init-xterm) and call it a day.
* If ‘kitty-use-full-keyboard’ has been set to non-nil,
‘terminal-init-xterm-kitty’ will send to the terminal the escape
sequence enabling full keyboard mode (CSI ? 2 0 1 7 h), set up
‘input-decode-map’ and ‘local-function-key-map’ as appropriate for
that mode, set ‘input-decode-preserve-echo’ to ‘t’, and perform other
xterm-like initialization such as bracketed paste, clipboard/selection
control, mouse, etc.
This bug report was last modified 6 years and 234 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.