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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: rgm <at> gnu.org, 17497 <at> debbugs.gnu.org
Subject: Re: bug#17497: 24.4.50; TTY menu glitches
Date: Fri, 16 May 2014 13:26:59 +0300

> Date: Fri, 16 May 2014 13:42:54 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: 17497 <at> debbugs.gnu.org
> 
> Just for the record, TTY menus are even more broken with Eterm.

How is this more broken?  All I see is the same problem with artifacts
left behind where they shouldn't be.  Like in your original
screenshots.  The number of artifacts is not important; even one of
them is a sign of some problem.

Do you see in the termscript any commands to write these artifacts?
E.g., the red-background "Close" was presumably the selected menu item
at some previous time; do you see a command to overwrite that with the
blue-background "Close" (or something else) in insert mode?

Is there any difference in what you see if you do that in a buffer
which is large enough to fill the entire window with text, like
xdisp.c in its first portion, where there's a large commentary?  IOW,
do these problems depend on what was on the screen before the menu was
dropped down?

The TTY menus work by overwriting portions of the glyph matrix with
the text derived from the menu.  The screen is updated by the normal
Emacs code, which was not touched at all.  So I don't understand why
these artifacts appear when menus are displayed, but not with normal
buffer text display...

Could this be a buffering issue?  Maybe adding some fflush calls will
make a difference?  (Not that I understand how buffering could change
the final result.)

Previous Next

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