bug#17497: 24.4.50; TTY menu glitches

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 05 Jun 2014 04:21:51 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: Thomas Dickey <dickey@his.com>, 17497@debbugs.gnu.org,
>  Eli Zaretskii <eliz@gnu.org>
> 
> > Or rather, no, don't bother, because even there might be problem in how
> > we process the input escape sequences, these are unrelated to the
> > display glitches we see.  So let's focus on the display glitches.
> 
> You could cut the discussion short by making the check that I suggested:
> logging the decoded character/special-key values to look for instances
> where the decoding returns individual bytes.

I don't think this is the problem in this case.  The arrow keys are
clearly decoded correctly and obeyed, as we see the reaction to them,
which is to redraw certain portions of the screen.  It's not like an
arrow key we get from the keyboard is sent verbatim to the terminal;
rather, Emacs interprets that key as a command to change the
background of two screen lines, and then sends the related commands,
including cursor motion, to the terminal.  IOW, the cursor motion
commands sent to the terminal are not what we receive from the
keyboard, they are generated by Emacs using a non-trivial logic in
cmgoto (which could decide that it is better to send a single newline
character, if it needs to move down just one line, or move to the
upper-left corner of the screen, for example).

Moreover, using C-n and C-p, which are single bytes, doesn't make the
problem go away.

So some other factor is at work here.  Keyboard input is unrelated,
at least as far as Emacs's code is concerned.