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

[Yuri Khan <yurivkhan@gmail.com>]

On Fri, Dec 21, 2018 at 3:41 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > 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);
> >         }

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

The problem disappears if I comment out this one ‘clear_message’.

I looked for its history.

* In the beginning (1992-01-29 by Jim Blandy), it was unconditional.
* 1994-05-11 Karl Heuer: “Preserve echo area on async buffer switch.”
* 1994-08-19 Richard M. Stallman: “Don’t show buffer-events to the user.”
* 1998-08-08 Richard M. Stallman: “When input method returns no chars,
call cancel_echoing. Restore the previous echo area message and
this_command_keys, too.”
* 1999-07-22 Gerd Moellmann: (slight refactoring)
* 1999-08-22 Gerd Moellmann: (more refactoring)
* 2005-05-11 Gerd Moellmann: “Don't clear current message for help events; …”
* 2012-05-07 Jérémy Compostella: “Don't clear the echo area if there's
no message to clear.”

That is, over time, various conditions were added around this clear,
for various reasons. The patch about input method returning no
characters uses the same kind of workaround, which is where I got this
idea.

Thing is, I do not understand what the original purpose was. It only
matters during the short interval after the initial character of the
key sequence is read, and until either the sequence is finished or
‘echo-keystrokes’ seconds elapse, and it seems to only provide
immediate visual feedback for pressing a prefix key. (What am I
overlooking?)

Also, I cannot easily add a new condition at this particular point. It
happens when Emacs reads each character of the sequence that will
eventually turn out to map to an empty one, but I do not know that
will be the case until the end.

Or do I?

In the specific use case of Kitty’s full keyboard mode, the condition
that I’m looking for is “The first character of the sequence currently
being read is ESC”. This is because in this mode the <escape> key
sends not just an ESC character but a whole ESC _ K p A y ESC \
sequence. That is, visual feedback is not necessary for a sole ESC
character and any sequence starting with ESC.

That condition is detectable in read_key_sequence and would need to be
passed into read_char. I could probably add a new argument to
read_char, or invent more values for its COMMANDFLAG argument. The new
logic would be governed by a terminal-local flag that essentially
means “on this terminal, the ESC character always means a special key
and never the key <escape>”, or a terminal-local set of characters
that always start special keys.

Do you think this is a better course of action?

> >> Also, who/where do you intend to set input-decode-preserve-echo?
> Ah, so you're planning to set it once and for all globally?

Terminal-locally, if it’s any better.

> That would really make it a workaround more than a fix, I think.