bug#33749: 26.1; input-decode-map to empty vector should preserve echo area

[Yuri Khan]

On Thu, Dec 20, 2018 at 1:05 AM Stefan Monnier <monnier@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.