bug#17497: 24.4.50; TTY menu glitches

[Eli Zaretskii <eliz@gnu.org>]

[I asked Thomas for his expert opinion on this strange issue, and he
graciously agreed.]

> Date: Sun, 01 Jun 2014 11:26:57 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com
> 
> On Sun, Jun 01, 2014 at 06:07:33PM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 31 May 2014 16:09:47 -0400
> > > From: Thomas Dickey <dickey@his.com>
> > > Cc: dickey@his.com
> > > 
> > > The discussion sounds like a common problem: terminals send cursor- and
> > > function-keys generally as a sequence of bytes, requiring an application
> > > to wait for each sequence to complete.  If each keystroke causes the
> > > application to do something that writes a lot of text to the screen (such
> > > as scrolling), it's possible to have some of those sequences timeout.
> > > Once that happens, the application doesn't see cursor-keys, it sees the
> > > individual bytes - which can be interpreted differently (including echoing
> > > and further messing up the display).
> > > 
> > > While I'm aware that Emacs doesn't use ncurses for screen optimization,
> > > which is the same issue implied in the description of ESCDELAY in the
> > > ncurses manpage, which begins
> > > 
> > >        ESCDELAY
> > >             Specifies the total time, in milliseconds, for  which  ncurses
> > >             will  await  a  character sequence, e.g., a function key.  The
> > >             default value, 1000 milliseconds, is  enough  for  most  uses.
> > >             However, it is made a variable to accommodate unusual applica‐
> > >             tions.
> > > 
> > >             The most common instance where you may  wish  to  change  this
> > >             value  is to work with slow hosts, e.g., running on a network.
> > >             If the host cannot read characters  rapidly  enough,  it  will
> > >             have  the  same effect as if the terminal did not send charac‐
> > >             ters rapidly enough.  The library will still see a timeout.
> > 
> > Thanks.
> > 
> > However, what puzzles me is that the code which implements text-mode
> > menus doesn't change at all how Emacs handles display on a TTY.  We
> > just overwrite portions of the display with the menu text in some
> > internal data structure, then hand out that structure to the code
> > which updates the screen, as if the buffer text has changed.  So how
> > come we never saw similar problems with normal Emacs display on a TTY,
> > e.g. when the user presses PgDn to scroll the text?
> 
> Scrolling one line at a time versus scrolling the whole page differs
> most noticeably if the application doesn't (or can't) use a terminal's
> scrolling features.  If it doesn't scroll, then the whole screen has to
> be repainted for each update.

Emacs optimizes redrawing by comparing the previous and the desired
display, and then only repainting the changed parts.

None of that changes when the menu is displayed, we just overwrite
portions of the desired display data structure, then call the normal
redrawing routines.  That's why it puzzles me why the problems are
being reported only for the menus.

> Repainting the screen after scrolling one line is going to be much slower
> than repainting the screen after scrolling one page.

Yes, I understand.  But repainting the menu when the user presses,
e.g., the down arrow, is no different: Emacs just repaints the
previously-selected menu item in the normal color, then repaints the
one below it in the "selected" color.  (Actually, since the menu item
is usually shorter than the terminal width, only part of each of those
2 lines is redrawn.)

> > Btw, is it OK to CC the Emacs bug tracker, so that this discussion is
> > recorded there?
> 
> yes

Thanks.  The 17497@debbugs.gnu.org address above will achieve that.