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 > > Cc: Thomas Dickey , 17497@debbugs.gnu.org, > > Eli Zaretskii > > > > > 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 http://invisible-island.net ftp://invisible-island.net