GNU bug report logs - #17497
24.4.50; TTY menu glitches

Previous Next

Full log

Message #143 received at 17497 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Thomas Dickey <dickey <at> his.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17497 <at> debbugs.gnu.org
Subject: Re: bug#17497: 24.4.50; TTY menu glitches
Date: Tue, 03 Jun 2014 09:43:04 -0400

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.

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?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.