bug#29150: Fwd: 26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)

[Eli Zaretskii <eliz@gnu.org>]

> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
> Date: Sun, 05 Nov 2017 21:34:30 +0100
> 
> in case of a button down event, `describe-key' has some trickery to also
> read the forthcoming up event. The following patch makes this trickery
> work with xterm-mouse-mode.

Thanks.  Do you understand why read-key-sequence-vector works with
xt-mouse, while read-event doesn't?  If so, can you elaborate on that?

Also, I take it that you assume there will be only one element in the
array returned by read-key-sequence-vector, is that right?  If so, how
sure are we that this will always be the case?  Because if the
assumption could be false, this change will have Emacs wait for some
other input, and the user might think that Emacs hanged.

Anyway, in general, I'm wary of such changes, which replace one API
for reading input by another, which works subtly differently.  We had
in the recent past several incidents where similar changes seemed to
work, only to reveal many moons later that some rarely-used but useful
functionality stopped working or became semi-broken.  So I think I'd
prefer a fix that is specific to xt-mouse (assuming that we can
reliably detect that the clicks come from xt-mouse), and leave the
other use cases alone.  If such a solution is possible and makes
sense, we could even install it on the release branch.

> PS: It would be nice, if that person also can have a look at patch #29104

It's in my queue, if no one else beats me to it.  And there, too, more
detailed description of what you saw and what led you to your proposed
solution might go a long way towards admitting the change sooner.