bug#17497: 24.4.50; TTY menu glitches

[Thomas Dickey]

On Wed, Jun 04, 2014 at 12:07:24AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 03 Jun 2014 14:47:49 -0400
> > From: Thomas Dickey <dickey@his.com>
> > Cc: Thomas Dickey <dickey@his.com>, 17497@debbugs.gnu.org,
> >  Eli Zaretskii <eliz@gnu.org>
> > 
> > > Currently, we're not concerned about optimization, just about tracking
> > > down a display glitch.  The tricky part of this glitch is that if we
> > > record&replay Emacs's output, the "replay" does not suffer from the
> > > same glitch.
> > 
> > sure - but I gave my best answer at the outset.  The behavior which
> > you are describing won't show up by doing replay's, because it would
> > occur when you have input (from the keyboard) interfering with the
> > output.
> >  
> > > So apparently the terminal emulator behaves differently in the "live"
> > > case than in the "replay" case for some reason.  We tried to replay at
> > > different speeds to see if it was related to timing, but to no avail.
> > > 
> > > To me, the next logical explanation is that the terminal emulator's
> > > behavior is influenced y the relative timing of *input* and output.
> > 
> > :-)
> >  
> > > For that reasons, your ncurses explanation is very interesting, yet
> > > I can't imagine how it can be directly related since our "record&replay"
> > > is done "after" ncurses, directly in the stream between Emacs's process
> > > and the terminal emulator.
> > > 
> > > Do you have some other insight that could explain why the terminal
> > > emulator would react differently in the "live" case than in the
> > > "replay" case?
> > 
> > repeating: if the cursor-key sequence of characters is misinterpreted
> > (for example due to timeouts), then fragments of the sequences will
> > echo as unexpected characters.
> > 
> > Incidentally, if an *output* splits up an escape sequence across
> > buffers in fflush's, then that can also open up holes in timing.
> > But I think that's less of concern...
> 
> All this, including input interfering with output, happens during
> normal Emacs redisplay, but we have never heard any complaints about
> corrupted display like the ones we get with the menus.

The menus cover _half_ of the screen, defeating any attempt to speed up
scrolling by using the terminal's indexing/scrolling features.  In the
view without menus, the scrolled text (unless you're considering scrolling
a pane of a vertically split window), is full-width, and works with
the terminal's scrolling features.

(If I were debugging something of the sort we're discussing, I'd log
the input-stream in terms of what the application is seeing, to look
for broken cursor-up/down sequences).
 
> The Emacs code which outputs commands and text to the terminal does
> not know whether a menu has been dropped or not, it just compares the
> previous display with the desired one, and sends commands to update
> the regions of the screen that has been changed.

sure - we're talking about characters.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature