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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> There are many of these, that I considered it impractical to attempt
> to prevent them all from happening.

They're probably not all guilty.  That's why I'm asking if you've been
able to find which one is the culprit.

>           safe_run_hooks (Qecho_area_clear_hook);
> →         clear_message (1, 0);
>         }
[...]
>   if (INTERACTIVE && t < mock_input)
> →   echo_truncate (echo_start);
>
[...]
>       if (INTERACTIVE && t < mock_input)
> →       echo_truncate (echo_local_start);
>       this_command_key_count = keys_local_start;

Are you saying that if you neuter all three of those, the problem
disappears?
If you keep any one of those is the problem still present?

>> 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.

Ah, so you're planning to set it once and for all globally?
That would really make it a workaround more than a fix, I think.


        Stefan