bug#17497: 24.4.50; TTY menu glitches

[Thomas Dickey <dickey@his.com>]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

On Tue, Jun 03, 2014 at 09:43:04AM -0400, Stefan Monnier wrote:
> Hi Thomas,
> 
> >> Most of the file, however, consists of repainting the menu.
> > By the way, since the menu covers only half the screen, there aren't
> > any general-purpose scrolling optimizations that would help.  (xterm
> > does support left/right margins, which would be interesting to explore
> > in this area).  What ncurses does when it's getting behind is to drop
> > updates - the typeahead feature:
> 
> 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...

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]