* bug#17497: 24.4.50; TTY menu glitches
@ 2014-05-15 12:26 Dmitry Antipov
2014-05-15 17:37 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Dmitry Antipov @ 2014-05-15 12:26 UTC (permalink / raw
To: 17497
[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]
Now I'm seeing two TTY menu glitches:
0) Double-"selected" item (actually selected item on this screenshot
is "New Window Below").
1) Out-of-menu "--" draw combined with incorrect help text in echo area.
$TERM is rxvt-unicode (version 9.20), if that matters.
Dmitry
In GNU Emacs 24.4.50.3 (x86_64-unknown-linux-gnu)
of 2014-05-15 on localhost.localdomain
Repository revision: 117110 dmantipov@yandex.ru-20140515100645-4wktg3eo5f0wpbob
System Description: Fedora release 20 (Heisenbug)
Configured using:
`configure --prefix=/not/exists --enable-gcc-warnings
--enable-check-lisp-object-type --enable-checking --without-x
--without-all --disable-acl 'CFLAGS=-O0 -g3''
Configured features:
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
[ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ B ESC [ B ESC [ A ESC [ A ESC [ A ESC [ B ESC [ B
ESC [ B ESC [ B ESC [ A ESC [ B ESC [ B ESC [ B ESC
[ A ESC [ A ESC [ A ESC [ A ESC [ B ESC [ A ESC [ A
ESC [ A ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B C-g
ESC [ B ESC [ B ESC x e m a c s DEL DEL DEL DEL DEL
DEL r e p o TAB r TAB RET
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
End of buffer [2 times]
delete-backward-char: Text is read-only
Making completion list...
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)
Memory information:
((conses 16 73001 4484)
(symbols 48 16870 0)
(miscs 40 33 117)
(strings 32 10242 5816)
(string-bytes 1 279721)
(vectors 16 7679)
(vector-slots 8 331222 25610)
(floats 8 60 583)
(intervals 56 203 4)
(buffers 960 12)
(heap 1024 23973 1892))
[-- Attachment #2: glitch0.png --]
[-- Type: image/png, Size: 8736 bytes --]
[-- Attachment #3: glitch1.png --]
[-- Type: image/png, Size: 10572 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-15 12:26 Dmitry Antipov
@ 2014-05-15 17:37 ` Eli Zaretskii
2014-05-16 6:36 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-15 17:37 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 17497
> Date: Thu, 15 May 2014 16:26:25 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
>
> Now I'm seeing two TTY menu glitches:
>
> 0) Double-"selected" item (actually selected item on this screenshot
> is "New Window Below").
>
> 1) Out-of-menu "--" draw combined with incorrect help text in echo area.
>
> $TERM is rxvt-unicode (version 9.20), if that matters.
Any hope of a reproducible recipe? I don't see this on the systems to
which I have access.
FWIW, this looks like a deja-vu of the phenomenon described in
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00546.html.
As concluded (after a long discussion) in
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00667.html,
we never actually understood why this happens. Maybe try to play with
the size of your TTY window, and see if that changes anything. Or
switch to xterm instead of rxvt.
Also, you could look into a termscript file to see whether Emacs
indeed wrote 2 lines with the red background in the first snapshot, or
wrote the "--" string at incorrect coordinates in the second. The
discussion mentioned above concluded that perfectly correct terminal
commands caused strange unexplained effects on the screen.
> System Description: Fedora release 20 (Heisenbug)
^^^^^^^^^
On second thought, a system with that description is supposed to do
this, no?
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-15 17:37 ` Eli Zaretskii
@ 2014-05-16 6:36 ` Glenn Morris
2014-05-16 6:38 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-16 6:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Dmitry Antipov, 17497
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Using "xfce4-terminal 0.6.3 (Xfce 4.10)", I did
emacs-24.3.91 -Q -nw
M-x menu-bar-open RET
then simply held down the down array, and very quickly got it to look
like the first attached image. By holding down the down arrow for a bit,
then the up arrow for a bit, then the down arrow, etc, I got the second
image. It's not 100% reproducible, but seemed to happen fairly often.
I don't expect to hold down the arrow keys in normal usage. :)
[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 33411 bytes --]
[-- Attachment #3: 2.png --]
[-- Type: image/png, Size: 36289 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 6:36 ` Glenn Morris
@ 2014-05-16 6:38 ` Glenn Morris
2014-05-16 6:53 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-16 6:38 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Dmitry Antipov, 17497
Glenn Morris wrote:
> then simply held down the down array, and very quickly got it to look
s/array/arrow
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 6:38 ` Glenn Morris
@ 2014-05-16 6:53 ` Glenn Morris
2014-05-16 8:48 ` Eli Zaretskii
2014-05-16 9:42 ` Dmitry Antipov
0 siblings, 2 replies; 70+ messages in thread
From: Glenn Morris @ 2014-05-16 6:53 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Dmitry Antipov, 17497
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
And with the same strategy under "XTerm(303)", I quickly got the attached.
I don't normally use xterm, though, and it must be misconfigured
somehow, because pressing "M-x" produces LATIN SMALL LETTER O WITH
STROKE... :)
[-- Attachment #2: 3.png --]
[-- Type: image/png, Size: 7528 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 6:53 ` Glenn Morris
@ 2014-05-16 8:48 ` Eli Zaretskii
2014-05-16 15:47 ` Glenn Morris
2014-05-16 9:42 ` Dmitry Antipov
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-16 8:48 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, 17497@debbugs.gnu.org
> Date: Fri, 16 May 2014 02:53:59 -0400
>
> And with the same strategy under "XTerm(303)", I quickly got the attached.
> I don't normally use xterm, though, and it must be misconfigured
> somehow, because pressing "M-x" produces LATIN SMALL LETTER O WITH
> STROKE... :)
I have no idea what causes this. I cannot reproduce this, neither on
Windows, nor when running Emacs on GNU/Linux via PuTTY (which emulates
xterm).
Does this problem go away if you enlarge the terminal window such that
the entire File and Tools menus can be displayed without overlaying
the mode line? If the problems disappear then, perhaps we could solve
them by limiting the number of displayed menu items some more.
If enlarging the window doesn't help, then I don't know what to do,
unless someone shows me a recipe I can use to reproduce the problem on
some machine where I can debug them. Failing that, perhaps some
terminfo expert could analyze the termscript and show what we do
wrongly. Last time I looked at termscript produced in a similar case,
it looked entirely legitimate, i.e. at no time did Emacs send a
terminal command to write to the portions of display where a
screenshot showed incorrectly displayed text, and every time a
red-background menu item was incorrectly left behind, there was a
clear command in the termscript that told the terminal to redraw that
very item with the normal (blue) background. IOW, it looked like for
some reason the terminal was not obeying the commands it was sent.
Doers anyone know why would this happen?
It could also be some timing problem, specific to X, in which case
someone will have to explain how to avoid that, because I have no
idea.
Does this happen if you use the menu "reasonably", i.e. without
leaning on arrow keys? Does it happen if you use C-p instead of the
down arrow?
I'm at a loss here...
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 6:53 ` Glenn Morris
2014-05-16 8:48 ` Eli Zaretskii
@ 2014-05-16 9:42 ` Dmitry Antipov
2014-05-16 10:26 ` Eli Zaretskii
2014-05-16 10:46 ` Eli Zaretskii
1 sibling, 2 replies; 70+ messages in thread
From: Dmitry Antipov @ 2014-05-16 9:42 UTC (permalink / raw
To: Glenn Morris, Eli Zaretskii; +Cc: 17497
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
On 05/16/2014 10:53 AM, Glenn Morris wrote:
> And with the same strategy under "XTerm(303)", I quickly got the attached.
I found this issue XTerm-compatible too.
Just for the record, TTY menus are even more broken with Eterm.
Dmitry
[-- Attachment #2: eterm.png --]
[-- Type: image/png, Size: 52631 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 9:42 ` Dmitry Antipov
@ 2014-05-16 10:26 ` Eli Zaretskii
2014-05-16 10:46 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-16 10:26 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 17497
> Date: Fri, 16 May 2014 13:42:54 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 17497@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.)
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 9:42 ` Dmitry Antipov
2014-05-16 10:26 ` Eli Zaretskii
@ 2014-05-16 10:46 ` Eli Zaretskii
2014-05-16 14:59 ` Dmitry Antipov
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-16 10:46 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 17497
> Date: Fri, 16 May 2014 13:42:54 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 17497@debbugs.gnu.org
>
> Just for the record, TTY menus are even more broken with Eterm.
Does the change below help in any way?
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2014-04-18 08:35:09 +0000
+++ src/xdisp.c 2014-05-16 10:35:55 +0000
@@ -21307,6 +21307,8 @@ display_tty_menu_item (const char *item_
width, 0, FRAME_COLS (f) - 1, -1);
row->used[TEXT_AREA] = max (saved_used, row->used[TEXT_AREA]);
+ if (row->used[TEXT_AREA] > 0)
+ row->displays_text_p = 1;
row->truncated_on_right_p = saved_truncated;
row->hash = row_hash (row);
row->full_width_p = saved_width;
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 10:46 ` Eli Zaretskii
@ 2014-05-16 14:59 ` Dmitry Antipov
2014-05-16 15:26 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Dmitry Antipov @ 2014-05-16 14:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497
On 05/16/2014 02:46 PM, Eli Zaretskii wrote:
> Does the change below help in any way?
Unfortunately no, AFAICS.
Dmitry
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 14:59 ` Dmitry Antipov
@ 2014-05-16 15:26 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-16 15:26 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 17497
> Date: Fri, 16 May 2014 18:59:58 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 17497@debbugs.gnu.org
>
> On 05/16/2014 02:46 PM, Eli Zaretskii wrote:
>
> > Does the change below help in any way?
>
> Unfortunately no, AFAICS.
If you record in a termscript while doing what it takes to reproduce
the problem, and the dump that termscript to the screen, do you see
the same artifacts as you saw in Emacs?
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 8:48 ` Eli Zaretskii
@ 2014-05-16 15:47 ` Glenn Morris
2014-05-16 20:21 ` Eli Zaretskii
2014-05-17 9:56 ` Eli Zaretskii
0 siblings, 2 replies; 70+ messages in thread
From: Glenn Morris @ 2014-05-16 15:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Eli Zaretskii wrote:
> Does this problem go away if you enlarge the terminal window such that
> the entire File and Tools menus can be displayed without overlaying
> the mode line?
I maximized the xterm before starting Emacs, and still very quickly got
into the state where there is a duplicate "--" off to the right of the
real menu (same as my "1.png" from earlier). It does seem less common
with a bigger terminal though.
> Does this happen if you use the menu "reasonably", i.e. without
> leaning on arrow keys?
So far no, IME.
> Does it happen if you use C-p instead of the down arrow?
Leaning on C-p produces glitches, yes. Here's a fun one:
[-- Attachment #2: 4.png --]
[-- Type: image/png, Size: 7038 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 15:47 ` Glenn Morris
@ 2014-05-16 20:21 ` Eli Zaretskii
2014-05-17 9:56 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-16 20:21 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Fri, 16 May 2014 11:47:27 -0400
>
> > Does this happen if you use the menu "reasonably", i.e. without
> > leaning on arrow keys?
>
> So far no, IME.
Which means what? that the terminal somehow "optimizes out" some of
the commands it receives when they arrive at a high rate??
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-16 15:47 ` Glenn Morris
2014-05-16 20:21 ` Eli Zaretskii
@ 2014-05-17 9:56 ` Eli Zaretskii
2014-05-22 2:49 ` Eli Zaretskii
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-17 9:56 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Fri, 16 May 2014 11:47:27 -0400
>
> > Does this problem go away if you enlarge the terminal window such that
> > the entire File and Tools menus can be displayed without overlaying
> > the mode line?
>
> I maximized the xterm before starting Emacs, and still very quickly got
> into the state where there is a duplicate "--" off to the right of the
> real menu (same as my "1.png" from earlier). It does seem less common
> with a bigger terminal though.
>
> > Does this happen if you use the menu "reasonably", i.e. without
> > leaning on arrow keys?
>
> So far no, IME.
>
> > Does it happen if you use C-p instead of the down arrow?
>
> Leaning on C-p produces glitches, yes. Here's a fun one:
Could both of you please record the terminal commands issued while you
reproduce the problem in a termscript, and then replay that termscript
to the same terminal (outside Emacs) with the attached shell script?
I'm interested to see whether the problem is reproduced by sending the
same commands at a low rate.
If sleeping for 2 seconds doesn't reproduce the problem, maybe try
decreasing the sleep time until it does.
TIA
[-- Attachment #2: script --]
[-- Type: application/octet-stream, Size: 179 bytes --]
#! /bin/sh
# Invoke as "script FILE"
l=`wc -l $1 | awk '{ print $1 }'`
i=1
while (expr $i "<=" $l > /dev/null); do
sed -n -e `echo $i`p $1 && sleep 2 && i=`expr $i "+" 1`;
done
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-17 9:56 ` Eli Zaretskii
@ 2014-05-22 2:49 ` Eli Zaretskii
2014-05-22 5:44 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 2:49 UTC (permalink / raw
To: rgm, dmantipov; +Cc: 17497
Ping! Could you please do what I asked below? Thanks.
> Date: Sat, 17 May 2014 12:56:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
>
> Could both of you please record the terminal commands issued while you
> reproduce the problem in a termscript, and then replay that termscript
> to the same terminal (outside Emacs) with the attached shell script?
> I'm interested to see whether the problem is reproduced by sending the
> same commands at a low rate.
>
> If sleeping for 2 seconds doesn't reproduce the problem, maybe try
> decreasing the sleep time until it does.
>
> TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 2:49 ` Eli Zaretskii
@ 2014-05-22 5:44 ` Glenn Morris
2014-05-22 7:51 ` Andreas Schwab
2014-05-22 16:19 ` Eli Zaretskii
0 siblings, 2 replies; 70+ messages in thread
From: Glenn Morris @ 2014-05-22 5:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
Replaying the termscript at full speed does not produce the same
glitches, if that makes any sense.
See attached image and assoicated termscript.
BTW, your script reduces to:
while read line; do
echo "$line"
sleep 2
done < "$1"
[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 34661 bytes --]
[-- Attachment #3: tscript3.xz --]
[-- Type: application/octet-stream, Size: 1644 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 5:44 ` Glenn Morris
@ 2014-05-22 7:51 ` Andreas Schwab
2014-05-22 15:58 ` Glenn Morris
2014-05-22 16:19 ` Eli Zaretskii
1 sibling, 1 reply; 70+ messages in thread
From: Andreas Schwab @ 2014-05-22 7:51 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
Glenn Morris <rgm@gnu.org> writes:
> Replaying the termscript at full speed does not produce the same
> glitches, if that makes any sense.
Then it can only be a bug in the terminal emulator.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 7:51 ` Andreas Schwab
@ 2014-05-22 15:58 ` Glenn Morris
2014-05-22 17:19 ` Andreas Schwab
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-22 15:58 UTC (permalink / raw
To: Andreas Schwab; +Cc: dmantipov, 17497
Andreas Schwab wrote:
> Glenn Morris <rgm@gnu.org> writes:
>
>> Replaying the termscript at full speed does not produce the same
>> glitches, if that makes any sense.
>
> Then it can only be a bug in the terminal emulator.
Then it's common to several of them, as has already been said.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 5:44 ` Glenn Morris
2014-05-22 7:51 ` Andreas Schwab
@ 2014-05-22 16:19 ` Eli Zaretskii
2014-05-22 16:26 ` Glenn Morris
2014-05-22 16:43 ` Eli Zaretskii
1 sibling, 2 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 16:19 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Thu, 22 May 2014 01:44:05 -0400
>
> Replaying the termscript at full speed does not produce the same
> glitches, if that makes any sense.
That's weird. Earlier you said that if you don't lean on the arrow
keys, but press them at normal typing speed, the problem doesn't
happen as well, is that right? If so, perhaps you could produce a
termscript for the same sequence of keypresses, just at that "normal"
speed, so we could compare them. (If one of the termscripts has fewer
keypresses than the other, it doesn't matter, as long as you press the
same keys.)
> BTW, your script reduces to:
>
> while read line; do
> echo "$line"
> sleep 2
> done < "$1"
Thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:19 ` Eli Zaretskii
@ 2014-05-22 16:26 ` Glenn Morris
2014-05-22 16:46 ` Eli Zaretskii
2014-05-22 16:43 ` Eli Zaretskii
1 sibling, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-22 16:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
Eli Zaretskii wrote:
> That's weird. Earlier you said that if you don't lean on the arrow
> keys, but press them at normal typing speed, the problem doesn't
> happen as well, is that right?
So far I have not seen it to occur without me leaning on keys, but it
could be that it only happens on say 1/100 key presses, as opposed to
when the key rate is high. I don't use text-mode menus normally.
> If so, perhaps you could produce a termscript for the same sequence of
> keypresses, just at that "normal" speed, so we could compare them. (If
> one of the termscripts has fewer keypresses than the other, it doesn't
> matter, as long as you press the same keys.)
You mean I can replace "lean on the down key, lean on the up key, lean
on the down key" with just "down, up, down"?
If so, I'll give it a go later on.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:19 ` Eli Zaretskii
2014-05-22 16:26 ` Glenn Morris
@ 2014-05-22 16:43 ` Eli Zaretskii
2014-05-22 16:54 ` Glenn Morris
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 16:43 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
> Date: Thu, 22 May 2014 19:19:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
>
> > From: Glenn Morris <rgm@gnu.org>
> > Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> > Date: Thu, 22 May 2014 01:44:05 -0400
> >
> > Replaying the termscript at full speed does not produce the same
> > glitches, if that makes any sense.
>
> That's weird.
Wait, maybe I misunderstood you. Did you mean that replaying at full
speed (i.e. without the 'sleep' line, I presume?) makes the glitches
go away, or did you mean there are still glitches, but they look
different on the screen?
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:26 ` Glenn Morris
@ 2014-05-22 16:46 ` Eli Zaretskii
2014-05-30 9:22 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 16:46 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Thu, 22 May 2014 12:26:47 -0400
>
> > If so, perhaps you could produce a termscript for the same sequence of
> > keypresses, just at that "normal" speed, so we could compare them. (If
> > one of the termscripts has fewer keypresses than the other, it doesn't
> > matter, as long as you press the same keys.)
>
> You mean I can replace "lean on the down key, lean on the up key, lean
> on the down key" with just "down, up, down"?
Actually, something like 20 times down, then 20 times up would be
better, I think.
Also, if you revert revision 117033 on emacs-24 branch (or try with a
binary built before Apr 29, if you keep them), does the problem still
exist?
TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:43 ` Eli Zaretskii
@ 2014-05-22 16:54 ` Glenn Morris
2014-05-22 17:07 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-22 16:54 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
Eli Zaretskii wrote:
> Wait, maybe I misunderstood you. Did you mean that replaying at full
> speed (i.e. without the 'sleep' line, I presume?) makes the glitches
> go away, or did you mean there are still glitches, but they look
> different on the screen?
With no sleep, there are no glitches (that I could see).
I certainly did not end up with that stray "--" off to the right.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:54 ` Glenn Morris
@ 2014-05-22 17:07 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 17:07 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Thu, 22 May 2014 12:54:26 -0400
>
> With no sleep, there are no glitches (that I could see).
> I certainly did not end up with that stray "--" off to the right.
IOW, sending commands at fast rate by leaning on the keys does produce
the glitches, but replaying the same commands at fast rate doesn't.
Curiouser and curiouser...
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 15:58 ` Glenn Morris
@ 2014-05-22 17:19 ` Andreas Schwab
2014-05-22 17:29 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Andreas Schwab @ 2014-05-22 17:19 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
Glenn Morris <rgm@gnu.org> writes:
> Andreas Schwab wrote:
>
>> Glenn Morris <rgm@gnu.org> writes:
>>
>>> Replaying the termscript at full speed does not produce the same
>>> glitches, if that makes any sense.
>>
>> Then it can only be a bug in the terminal emulator.
>
> Then it's common to several of them, as has already been said.
That's very well possible, since they are often just forks of each
other.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 17:19 ` Andreas Schwab
@ 2014-05-22 17:29 ` Glenn Morris
2014-05-22 17:53 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-22 17:29 UTC (permalink / raw
To: Andreas Schwab; +Cc: dmantipov, 17497
Andreas Schwab wrote:
> That's very well possible, since they are often just forks of each
> other.
OK, so far people have seen such issues with
xterm 303
rxvt-unicode 9.20
xfce4-terminal 0.6.3
eterm
whatever martin was using in
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00462.html
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 17:29 ` Glenn Morris
@ 2014-05-22 17:53 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-22 17:53 UTC (permalink / raw
To: Glenn Morris; +Cc: schwab, dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 22 May 2014 13:29:40 -0400
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
>
> whatever martin was using in
> http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00462.html
Not sure that was the same problem, as it disappeared when replayed
with a script like the one you used. It also disappeared in xterm on
the same machine, and when the size of the terminal window was
enlarged.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-22 16:46 ` Eli Zaretskii
@ 2014-05-30 9:22 ` Eli Zaretskii
2014-05-31 2:22 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-30 9:22 UTC (permalink / raw
To: rgm, dmantipov; +Cc: 17497
> Date: Thu, 22 May 2014 19:46:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
>
> > From: Glenn Morris <rgm@gnu.org>
> > Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> > Date: Thu, 22 May 2014 12:26:47 -0400
> >
> > > If so, perhaps you could produce a termscript for the same sequence of
> > > keypresses, just at that "normal" speed, so we could compare them. (If
> > > one of the termscripts has fewer keypresses than the other, it doesn't
> > > matter, as long as you press the same keys.)
> >
> > You mean I can replace "lean on the down key, lean on the up key, lean
> > on the down key" with just "down, up, down"?
>
> Actually, something like 20 times down, then 20 times up would be
> better, I think.
>
> Also, if you revert revision 117033 on emacs-24 branch (or try with a
> binary built before Apr 29, if you keep them), does the problem still
> exist?
Ping! Any more info on this?
TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-30 9:22 ` Eli Zaretskii
@ 2014-05-31 2:22 ` Glenn Morris
2014-05-31 8:20 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-05-31 2:22 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
Eli Zaretskii wrote:
>> Also, if you revert revision 117033 on emacs-24 branch (or try with a
>> binary built before Apr 29, if you keep them), does the problem still
>> exist?
Reverting 117033: still glitchy.
> > > If so, perhaps you could produce a termscript for the same sequence of
> > > keypresses, just at that "normal" speed, so we could compare them. (If
> > > one of the termscripts has fewer keypresses than the other, it doesn't
> > > matter, as long as you press the same keys.)
> >
> > You mean I can replace "lean on the down key, lean on the up key, lean
> > on the down key" with just "down, up, down"?
>
> Actually, something like 20 times down, then 20 times up would be
> better, I think.
OK, so in trying to do this, I have noticed it glitching when I press
the keys at normal speed. So I presume it's not useful to send you that
comparison after all.
See attached image and associated typescript.
In this case I think I just opened the menu-bar and pressed the down
arrow three times at normal speed.
FWIW, I could not make it happen on a RHEL 6.5 system at all.
But on a Debian testing system, it happens with multiple terminal emulators.
(I suspect this is going to be one of those things you need to be able
to reproduce to fix...)
[-- Attachment #2: 2.png --]
[-- Type: image/png, Size: 34593 bytes --]
[-- Attachment #3: t2.txt.xz --]
[-- Type: application/octet-stream, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-31 2:22 ` Glenn Morris
@ 2014-05-31 8:20 ` Eli Zaretskii
2014-05-31 17:35 ` Glenn Morris
2014-06-01 15:11 ` Eli Zaretskii
0 siblings, 2 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-05-31 8:20 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Fri, 30 May 2014 22:22:29 -0400
>
> >> Also, if you revert revision 117033 on emacs-24 branch (or try with a
> >> binary built before Apr 29, if you keep them), does the problem still
> >> exist?
>
> Reverting 117033: still glitchy.
OK, one suspect down.
> OK, so in trying to do this, I have noticed it glitching when I press
> the keys at normal speed. So I presume it's not useful to send you that
> comparison after all.
No, it's not useful. But I wonder why earlier you thought that this
didn't happen at normal speed. Is it more rare at normal speed?
> See attached image and associated typescript.
> In this case I think I just opened the menu-bar and pressed the down
> arrow three times at normal speed.
When I replay that typescript on fencepost.gnu.org (logging into it
via PuTTY, which emulates xterm), I see no glitches at all, FWIW.
Interestingly, there's a cursor shown in the image to the left of
"Visit New File" menu item; it shouldn't be there.
Moreover, if I login to fencepost, set my terminal's height to be 24
lines, like in your screenshot, and then record the termscript with
the same 3 keystrokes as you did, I get an identical script! So Emacs
behaves identically on these 2 systems, it's something in the terminal
emulators and/or the libraries they use that causes the differences in
behavior.
> FWIW, I could not make it happen on a RHEL 6.5 system at all.
> But on a Debian testing system, it happens with multiple terminal emulators.
>
> (I suspect this is going to be one of those things you need to be able
> to reproduce to fix...)
Can you reproduce the problem when you log into that Debian testing
system remotely, via some xterm emulator? If so, I'd appreciate an
SSH login to that system, and a directory with an Emacs tree to play
in. Thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-31 8:20 ` Eli Zaretskii
@ 2014-05-31 17:35 ` Glenn Morris
2014-06-01 15:11 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Glenn Morris @ 2014-05-31 17:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
Eli Zaretskii wrote:
> Can you reproduce the problem when you log into that Debian testing
> system remotely, via some xterm emulator? If so, I'd appreciate an
> SSH login to that system, and a directory with an Emacs tree to play
> in. Thanks.
Sorry, that is my laptop, and I don't have incoming ssh enabled on it,
and as a general rule don't want to. Nothing against you personally! :)
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-05-31 8:20 ` Eli Zaretskii
2014-05-31 17:35 ` Glenn Morris
@ 2014-06-01 15:11 ` Eli Zaretskii
2014-06-03 4:51 ` Glenn Morris
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-01 15:11 UTC (permalink / raw
To: rgm; +Cc: dmantipov, 17497
One more idea: can you try decreasing the number 900 in this snippet
from dispnew.c:
if (FRAME_TERMCAP_P (f))
{
/* Flush out every so many lines.
Also flush out if likely to have more than 1k buffered
otherwise. I'm told that some telnet connections get
really screwed by more than 1k output at once. */
FILE *display_output = FRAME_TTY (f)->output;
if (display_output)
{
ptrdiff_t outq = __fpending (display_output);
if (outq > 900
|| (outq > 20 && ((i - 1) % preempt_count == 0)))
fflush (display_output);
}
}
Or maybe even make display_output line-buffered. I wonder if that has
any effect on the problem.
TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
[not found] ` <20140601152657.GA15078@aerie.jexium-island.net>
@ 2014-06-01 16:25 ` Eli Zaretskii
2014-06-01 17:12 ` Thomas Dickey
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-01 16:25 UTC (permalink / raw
To: dickey; +Cc: 17497
[I asked Thomas for his expert opinion on this strange issue, and he
graciously agreed.]
> Date: Sun, 01 Jun 2014 11:26:57 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com
>
> On Sun, Jun 01, 2014 at 06:07:33PM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 31 May 2014 16:09:47 -0400
> > > From: Thomas Dickey <dickey@his.com>
> > > Cc: dickey@his.com
> > >
> > > The discussion sounds like a common problem: terminals send cursor- and
> > > function-keys generally as a sequence of bytes, requiring an application
> > > to wait for each sequence to complete. If each keystroke causes the
> > > application to do something that writes a lot of text to the screen (such
> > > as scrolling), it's possible to have some of those sequences timeout.
> > > Once that happens, the application doesn't see cursor-keys, it sees the
> > > individual bytes - which can be interpreted differently (including echoing
> > > and further messing up the display).
> > >
> > > While I'm aware that Emacs doesn't use ncurses for screen optimization,
> > > which is the same issue implied in the description of ESCDELAY in the
> > > ncurses manpage, which begins
> > >
> > > ESCDELAY
> > > Specifies the total time, in milliseconds, for which ncurses
> > > will await a character sequence, e.g., a function key. The
> > > default value, 1000 milliseconds, is enough for most uses.
> > > However, it is made a variable to accommodate unusual applica‐
> > > tions.
> > >
> > > The most common instance where you may wish to change this
> > > value is to work with slow hosts, e.g., running on a network.
> > > If the host cannot read characters rapidly enough, it will
> > > have the same effect as if the terminal did not send charac‐
> > > ters rapidly enough. The library will still see a timeout.
> >
> > Thanks.
> >
> > However, what puzzles me is that the code which implements text-mode
> > menus doesn't change at all how Emacs handles display on a TTY. We
> > just overwrite portions of the display with the menu text in some
> > internal data structure, then hand out that structure to the code
> > which updates the screen, as if the buffer text has changed. So how
> > come we never saw similar problems with normal Emacs display on a TTY,
> > e.g. when the user presses PgDn to scroll the text?
>
> Scrolling one line at a time versus scrolling the whole page differs
> most noticeably if the application doesn't (or can't) use a terminal's
> scrolling features. If it doesn't scroll, then the whole screen has to
> be repainted for each update.
Emacs optimizes redrawing by comparing the previous and the desired
display, and then only repainting the changed parts.
None of that changes when the menu is displayed, we just overwrite
portions of the desired display data structure, then call the normal
redrawing routines. That's why it puzzles me why the problems are
being reported only for the menus.
> Repainting the screen after scrolling one line is going to be much slower
> than repainting the screen after scrolling one page.
Yes, I understand. But repainting the menu when the user presses,
e.g., the down arrow, is no different: Emacs just repaints the
previously-selected menu item in the normal color, then repaints the
one below it in the "selected" color. (Actually, since the menu item
is usually shorter than the terminal width, only part of each of those
2 lines is redrawn.)
> > Btw, is it OK to CC the Emacs bug tracker, so that this discussion is
> > recorded there?
>
> yes
Thanks. The 17497@debbugs.gnu.org address above will achieve that.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 16:25 ` bug#17497: 24.4.50; TTY menu glitches Eli Zaretskii
@ 2014-06-01 17:12 ` Thomas Dickey
2014-06-01 17:18 ` Thomas Dickey
2014-06-01 18:39 ` Eli Zaretskii
0 siblings, 2 replies; 70+ messages in thread
From: Thomas Dickey @ 2014-06-01 17:12 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Sun, Jun 01, 2014 at 07:25:29PM +0300, Eli Zaretskii wrote:
> Emacs optimizes redrawing by comparing the previous and the desired
> display, and then only repainting the changed parts.
That's the intent - but
>
> None of that changes when the menu is displayed, we just overwrite
> portions of the desired display data structure, then call the normal
> redrawing routines. That's why it puzzles me why the problems are
> being reported only for the menus.
I downloaded tscript3.xz from message #50, and am cat'ing it (slowly)
to a 24x80 xterm. It very clearly is not repainting just changed portions.
At the very beginning of the script, the screen updates just a couple of
lines (old/new) as the cursor moves across menu items. But as soon as
the cursor goes past the menu items which are first shown, the program
is repainting the entire menu. Thereafter, even after it has returned
to the original view, there are occasional repaints of the entire menu,
as well as cursor movement to/from the "Close" entry.
Most of the file, however, consists of repainting the menu.
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 17:12 ` Thomas Dickey
@ 2014-06-01 17:18 ` Thomas Dickey
2014-06-01 18:45 ` Eli Zaretskii
2014-06-03 13:43 ` Stefan Monnier
2014-06-01 18:39 ` Eli Zaretskii
1 sibling, 2 replies; 70+ messages in thread
From: Thomas Dickey @ 2014-06-01 17:18 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
On Sun, Jun 01, 2014 at 01:12:44PM -0400, Thomas Dickey wrote:
> 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:
The curses library does ``line-breakout optimization'' by looking for
typeahead periodically while updating the screen. If input is found,
and it is coming from a tty, the current update is postponed until re-
fresh or doupdate is called again. This allows faster response to com-
mands typed in advance. Normally, the input FILE pointer passed to
newterm, or stdin in the case that initscr was used, will be used to do
this typeahead checking. The typeahead routine specifies that the file
descriptor fd is to be used to check for typeahead instead. If fd is
-1, then no typeahead checking is done.
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 17:12 ` Thomas Dickey
2014-06-01 17:18 ` Thomas Dickey
@ 2014-06-01 18:39 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-01 18:39 UTC (permalink / raw
To: dickey; +Cc: 17497
> Date: Sun, 01 Jun 2014 13:12:44 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com, 17497@debbugs.gnu.org
>
> I downloaded tscript3.xz from message #50, and am cat'ing it (slowly)
> to a 24x80 xterm. It very clearly is not repainting just changed portions.
> At the very beginning of the script, the screen updates just a couple of
> lines (old/new) as the cursor moves across menu items. But as soon as
> the cursor goes past the menu items which are first shown, the program
> is repainting the entire menu. Thereafter, even after it has returned
> to the original view, there are occasional repaints of the entire menu,
> as well as cursor movement to/from the "Close" entry.
I will look into this, thanks. I think I actually force full redraws
under some conditions. I will see if they are necessary.
But even these full repaints shouldn't be causing any artifacts as
shown in the screenshots, should they? Emacs sometimes redraws a full
screen (e.g., when you switch a frame on a TTY), but I never heard any
complaints about the results.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 17:18 ` Thomas Dickey
@ 2014-06-01 18:45 ` Eli Zaretskii
2014-06-01 19:46 ` Thomas Dickey
2014-06-03 13:43 ` Stefan Monnier
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-01 18:45 UTC (permalink / raw
To: dickey; +Cc: 17497
> Date: Sun, 01 Jun 2014 13:18:17 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 17497@debbugs.gnu.org
>
> What ncurses does when it's getting behind is to drop updates - the
> typeahead feature:
>
> The curses library does ``line-breakout optimization'' by looking for
> typeahead periodically while updating the screen. If input is found,
> and it is coming from a tty, the current update is postponed until re-
> fresh or doupdate is called again. This allows faster response to com-
> mands typed in advance. Normally, the input FILE pointer passed to
> newterm, or stdin in the case that initscr was used, will be used to do
> this typeahead checking. The typeahead routine specifies that the file
> descriptor fd is to be used to check for typeahead instead. If fd is
> -1, then no typeahead checking is done.
So buffering output more aggressively could help, is that what you are
saying?
We currently fflush the stream every 900 bytes and also every 10
screen lines or so. Does that sound reasonable?
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 18:45 ` Eli Zaretskii
@ 2014-06-01 19:46 ` Thomas Dickey
2014-06-02 15:17 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Thomas Dickey @ 2014-06-01 19:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On Sun, Jun 01, 2014 at 09:45:07PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 01 Jun 2014 13:18:17 -0400
> > From: Thomas Dickey <dickey@his.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 17497@debbugs.gnu.org
> >
> > What ncurses does when it's getting behind is to drop updates - the
> > typeahead feature:
> >
> > The curses library does ``line-breakout optimization'' by looking for
> > typeahead periodically while updating the screen. If input is found,
> > and it is coming from a tty, the current update is postponed until re-
> > fresh or doupdate is called again. This allows faster response to com-
> > mands typed in advance. Normally, the input FILE pointer passed to
> > newterm, or stdin in the case that initscr was used, will be used to do
> > this typeahead checking. The typeahead routine specifies that the file
> > descriptor fd is to be used to check for typeahead instead. If fd is
> > -1, then no typeahead checking is done.
>
> So buffering output more aggressively could help, is that what you are
> saying?
>
> We currently fflush the stream every 900 bytes and also every 10
> screen lines or so. Does that sound reasonable?
I don't think that will be enough: the output stream simply is not fast
enough to keep up. The typeahead feature is crude, but works. A more
elegant approach (perhaps complicated) would be to keep track of the
changes since the beginning of a repaint, and store _those_ into a
buffer which could be discarded if it is not written before the next
input character is detected.
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 19:46 ` Thomas Dickey
@ 2014-06-02 15:17 ` Eli Zaretskii
2014-06-02 16:14 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-02 15:17 UTC (permalink / raw
To: Thomas Dickey, Glenn Morris; +Cc: 17497
> Date: Sun, 01 Jun 2014 15:46:00 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com, 17497@debbugs.gnu.org
>
> > So buffering output more aggressively could help, is that what you are
> > saying?
> >
> > We currently fflush the stream every 900 bytes and also every 10
> > screen lines or so. Does that sound reasonable?
>
> I don't think that will be enough: the output stream simply is not fast
> enough to keep up.
That'd be strange, since it evidently does succeed to keep up when we
redraw the display "normally", i.e. not due to dropping down or
updating a menu.
Anyway, I took another look at all the screenshots posted in this bug
report, and my conclusion is that all of the artifacts seem to be
caused by 2 root causes:
. Incorrect position of the cursor when a menu item is redrawn.
This explains why some menu items are "duplicated" elsewhere in
the menu, and also why items that needed to be redrawn with blue
background (i.e. in the "non-selected" face) are left with the red
background of the "selected" face.
In all of these cases, it looks like the cursor was positioned at
the EOB of the buffer (*scratch*) displayed beneath the menu.
This is the "normal" cursor position, as Emacs perceives it, and
that's where redisplay leaves the cursor after updating the frame
display. We override that in the menu-display code, by sending a
cursor motion command after the frame is completely displayed; it
looks like in at least some of the cases this cursor motion
command was not obeyed.
. The insert mode is not turned off before some string is written to
the display.
This explains why we see menu items to the right of the menu: they
were "pushed" by writing some other text to their left, while in
insert mode. There are similar problems in some of the
screenshots with the help-echo displayed in the echo area.
Alternatively, this type of artifacts can also be explained by
incorrect cursor position in the horizontal axis. To decide which
explanation is correct, I'd need to see the artifacts when the
underlying window is full of some buffer text, not almost empty as
in *scratch*. Glenn, could I persuade you to try that and show
the screenshots?
Does the above ring any bells?
Please also note that Emacs tries to be "clever" about cursor motion
on a TTY: it chooses out of several possible methods of moving the
cursor, comparing their "costs" (see cm.c:cmgoto for details). So
it's possible that different cursor movements emit different commands
to the terminal driver, and somehow trigger these strange effects.
Finally, one difference between the "normal" screen update and the one
we use to display and update TTY menus is that the latter seems to
cause significantly more cursor motion. One possible way to cut down
on that is to set show-help-function to nil. Glenn, can I ask you to
try that and see if it helps in any way?
TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-02 15:17 ` Eli Zaretskii
@ 2014-06-02 16:14 ` Glenn Morris
2014-06-02 16:43 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-06-02 16:14 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, Thomas Dickey
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Eli Zaretskii wrote:
> explanation is correct, I'd need to see the artifacts when the
> underlying window is full of some buffer text, not almost empty as
> in *scratch*. Glenn, could I persuade you to try that and show
> the screenshots?
See 1.png.
> cause significantly more cursor motion. One possible way to cut down
> on that is to set show-help-function to nil. Glenn, can I ask you to
> try that and see if it helps in any way?
It does not help.
See 2.png. It leaves my screen like 3.png after closing the menu.
[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 56644 bytes --]
[-- Attachment #3: 2.png --]
[-- Type: image/png, Size: 55513 bytes --]
[-- Attachment #4: 3.png --]
[-- Type: image/png, Size: 34252 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-02 16:14 ` Glenn Morris
@ 2014-06-02 16:43 ` Eli Zaretskii
2014-06-02 16:46 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-02 16:43 UTC (permalink / raw
To: Glenn Morris; +Cc: 17497, dickey
> From: Glenn Morris <rgm@gnu.org>
> Cc: Thomas Dickey <dickey@his.com>, 17497@debbugs.gnu.org
> Date: Mon, 02 Jun 2014 12:14:05 -0400
>
> > explanation is correct, I'd need to see the artifacts when the
> > underlying window is full of some buffer text, not almost empty as
> > in *scratch*. Glenn, could I persuade you to try that and show
> > the screenshots?
>
> See 1.png.
Thanks. Inconclusive.
> > cause significantly more cursor motion. One possible way to cut down
> > on that is to set show-help-function to nil. Glenn, can I ask you to
> > try that and see if it helps in any way?
>
> It does not help.
> See 2.png. It leaves my screen like 3.png after closing the menu.
Not sure what that means, except that the terminal scrolled for some
reason.
Btw, did you use menu-bar-open (as opposed to F10) in all your
experiments till now, or just this time?
Thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-02 16:43 ` Eli Zaretskii
@ 2014-06-02 16:46 ` Glenn Morris
2014-06-02 16:56 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-06-02 16:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
Eli Zaretskii wrote:
> Btw, did you use menu-bar-open (as opposed to F10) in all your
> experiments till now, or just this time?
I generally (but not I think always) used menu-bar-open.
Some terminal emulators use F10 to open their own menus, and I could not
be bothered to figure out how to disable that. :)
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-02 16:46 ` Glenn Morris
@ 2014-06-02 16:56 ` Eli Zaretskii
2014-06-02 17:05 ` Glenn Morris
0 siblings, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-02 16:56 UTC (permalink / raw
To: Glenn Morris; +Cc: 17497, dickey
> From: Glenn Morris <rgm@gnu.org>
> Cc: dickey@his.com, 17497@debbugs.gnu.org
> Date: Mon, 02 Jun 2014 12:46:53 -0400
>
> I generally (but not I think always) used menu-bar-open.
Just FYI: doing so exposes a subtle bug, due to the fact that "M-x"
adds an item to the menu bar, which confuses the menu code if you use
horizontal arrows or C-f/C-b.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-02 16:56 ` Eli Zaretskii
@ 2014-06-02 17:05 ` Glenn Morris
0 siblings, 0 replies; 70+ messages in thread
From: Glenn Morris @ 2014-06-02 17:05 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
Eli Zaretskii wrote:
>> I generally (but not I think always) used menu-bar-open.
>
> Just FYI: doing so exposes a subtle bug, due to the fact that "M-x"
> adds an item to the menu bar, which confuses the menu code if you use
> horizontal arrows or C-f/C-b.
OK, well I did say that I used M-x menu-bar-open in my first post to
this report (which isn't even my bug report BTW... :) )
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17497#11
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 15:11 ` Eli Zaretskii
@ 2014-06-03 4:51 ` Glenn Morris
2014-06-03 7:03 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-06-03 4:51 UTC (permalink / raw
To: Eli Zaretskii; +Cc: dmantipov, 17497
Eli Zaretskii wrote:
> One more idea: can you try decreasing the number 900 in this snippet
> from dispnew.c:
I set it to 450: still glitchy.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 4:51 ` Glenn Morris
@ 2014-06-03 7:03 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-03 7:03 UTC (permalink / raw
To: Glenn Morris; +Cc: dmantipov, 17497
> From: Glenn Morris <rgm@gnu.org>
> Cc: dmantipov@yandex.ru, 17497@debbugs.gnu.org
> Date: Tue, 03 Jun 2014 00:51:50 -0400
>
> Eli Zaretskii wrote:
>
> > One more idea: can you try decreasing the number 900 in this snippet
> > from dispnew.c:
>
> I set it to 450: still glitchy.
Thanks for trying.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-01 17:18 ` Thomas Dickey
2014-06-01 18:45 ` Eli Zaretskii
@ 2014-06-03 13:43 ` Stefan Monnier
2014-06-03 18:47 ` Thomas Dickey
1 sibling, 1 reply; 70+ messages in thread
From: Stefan Monnier @ 2014-06-03 13:43 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 13:43 ` Stefan Monnier
@ 2014-06-03 18:47 ` Thomas Dickey
2014-06-03 21:07 ` Eli Zaretskii
2014-06-04 3:03 ` Stefan Monnier
0 siblings, 2 replies; 70+ messages in thread
From: Thomas Dickey @ 2014-06-03 18:47 UTC (permalink / raw
To: Stefan Monnier; +Cc: 17497, Thomas Dickey
[-- 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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 18:47 ` Thomas Dickey
@ 2014-06-03 21:07 ` Eli Zaretskii
2014-06-03 22:21 ` Thomas Dickey
2014-06-04 3:03 ` Stefan Monnier
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-03 21:07 UTC (permalink / raw
To: dickey; +Cc: 17497
> 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 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 21:07 ` Eli Zaretskii
@ 2014-06-03 22:21 ` Thomas Dickey
2014-06-04 6:54 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Thomas Dickey @ 2014-06-03 22:21 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 18:47 ` Thomas Dickey
2014-06-03 21:07 ` Eli Zaretskii
@ 2014-06-04 3:03 ` Stefan Monnier
2014-06-04 8:31 ` Thomas Dickey
1 sibling, 1 reply; 70+ messages in thread
From: Stefan Monnier @ 2014-06-04 3:03 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
> 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.
I do not understand what that means. By "cursor-key sequence of
characters" do you mean the escape sequence sent by the terminal to
Emacs or the cursor-motion escape sequences sent from Emacs to the
text terminal?
What timeouts are you referring to? Are you saying that the terminal
emulator has internal timeouts? If so, can you describe when and how
they come into play?
It seems you're saying that the escape sequences Emacs sends to the
terminal need to be within a single "packet", because if such an escape
sequence is split among several "fflush" the terminal emulator won't
wait indefinitely for the second chunk, and instead will timeout after
a fairly short wait and consider the escape sequence as "unexpected
characters".
Stefan
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-03 22:21 ` Thomas Dickey
@ 2014-06-04 6:54 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 6:54 UTC (permalink / raw
To: dickey; +Cc: 17497
> Date: Tue, 03 Jun 2014 18:21:55 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com, monnier@iro.umontreal.ca, 17497@debbugs.gnu.org
>
> > 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.
You can easily make the "normal" display do the same: just divide the
window in 2 halves by typing "C-x 3", then scroll one of them with
C-v or the arrow keys. If you actually lean on the scrolling key, you
will make sure output and input are intermingled.
If this situation were inherently conducive to display bugs, we would
have heard about it long time ago.
So I think there's something about the screen update due to menus that
triggers these problems. I just have run out of ideas about what that
factor(s) could be, and I don't have access to any system where this
happens to debug that.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 3:03 ` Stefan Monnier
@ 2014-06-04 8:31 ` Thomas Dickey
2014-06-04 9:10 ` Thomas Dickey
2014-06-04 13:06 ` Stefan Monnier
0 siblings, 2 replies; 70+ messages in thread
From: Thomas Dickey @ 2014-06-04 8:31 UTC (permalink / raw
To: Stefan Monnier; +Cc: 17497, Thomas Dickey
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
On Tue, Jun 03, 2014 at 11:03:08PM -0400, Stefan Monnier wrote:
> > 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.
>
> I do not understand what that means. By "cursor-key sequence of
> characters" do you mean the escape sequence sent by the terminal to
> Emacs or the cursor-motion escape sequences sent from Emacs to the
> text terminal?
From the terminal to Emacs.
Cursor up typically is
ESC [ A
three characters. Curses applications behave differently if you type those
three characters, one-by-one, because of timing.
> What timeouts are you referring to? Are you saying that the terminal
> emulator has internal timeouts? If so, can you describe when and how
> they come into play?
Typically the _application_ (Emacs) waits for completion of a control sequence.
> It seems you're saying that the escape sequences Emacs sends to the
> terminal need to be within a single "packet", because if such an escape
> sequence is split among several "fflush" the terminal emulator won't
> wait indefinitely for the second chunk, and instead will timeout after
> a fairly short wait and consider the escape sequence as "unexpected
> characters".
That's part of it. Usually the input (from the terminal to the application)
is more important.
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 8:31 ` Thomas Dickey
@ 2014-06-04 9:10 ` Thomas Dickey
2014-06-04 9:38 ` Eli Zaretskii
2014-06-04 13:06 ` Stefan Monnier
1 sibling, 1 reply; 70+ messages in thread
From: Thomas Dickey @ 2014-06-04 9:10 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Wed, Jun 04, 2014 at 04:31:02AM -0400, Thomas Dickey wrote:
> On Tue, Jun 03, 2014 at 11:03:08PM -0400, Stefan Monnier wrote:
> > > 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.
> >
> > I do not understand what that means. By "cursor-key sequence of
> > characters" do you mean the escape sequence sent by the terminal to
> > Emacs or the cursor-motion escape sequences sent from Emacs to the
> > text terminal?
>
> From the terminal to Emacs.
>
> Cursor up typically is
>
> ESC [ A
...normal mode - application mode is still three:
ESC O A
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 9:10 ` Thomas Dickey
@ 2014-06-04 9:38 ` Eli Zaretskii
2014-06-04 10:16 ` Eli Zaretskii
2014-06-04 16:09 ` Glenn Morris
0 siblings, 2 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 9:38 UTC (permalink / raw
To: Thomas Dickey, Glenn Morris; +Cc: 17497
On the hunch that the problems discussed here are caused by excess
movement of the cursor, I've made changes in revision 117203 on the
emacs-24 branch to avoid some of them. Please try that.
If the problems are still there, one last idea I have is to ifdef away
the code in tty_menu_activate that invokes the help-echo display:
/* Display the help-echo message for the currently-selected menu
item. */
if ((menu_help_message || prev_menu_help_message)
&& menu_help_message != prev_menu_help_message)
{
help_callback (menu_help_message,
menu_help_paneno, menu_help_itemno);
/* Move the cursor to the beginning of the current menu
item, so that screen readers and other accessibility aids
know where the active region is. */
cursor_to (sf, row, col);
prev_menu_help_message = menu_help_message;
}
This code invokes another update of the frame, in addition to the one
we already did when we called tty_menu_display immediately before
that. It also moves the cursor (which is positioned by the frame
update to where point is in the selected window). Maybe avoiding that
will avoid the problems.
If even that doesn't help, then try to ifdef away the calls to
tty_hide_cursor made by tty_menu_activate.
These two last ideas are the only differences I know of between a
"normal" redisplay and redisplay due to update of a menu. If even
they don't make any difference, I guess this bug will have to remain
open until someone debugs it on a system where the problem can be
reproduced.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 9:38 ` Eli Zaretskii
@ 2014-06-04 10:16 ` Eli Zaretskii
2014-06-04 16:08 ` Glenn Morris
2014-06-04 16:09 ` Glenn Morris
1 sibling, 1 reply; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 10:16 UTC (permalink / raw
To: dickey, rgm, Stefan Monnier; +Cc: 17497
Here's a simple recipe to generate screen updates very similar to the
ones caused by a menu update. Do they cause similar artifacts on the
offending terminal emulators?
emacs -Q -nw
Insert and evaluate this function:
(defun my-help (old new)
""
(message "We are at %s" (point)))
C-x 3
C-x C-f src/xdisp.c RET (any sufficiently large file will do)
M-x hl-line-mode RET
M-: (progn
(beginning-of-buffer)
(dotimes (i 40)
(put-text-property
(line-beginning-position)
(line-end-position)
'point-entered
'my-help)
(forward-line))) RET
Now move cursor down and up through the first 40 lines of the buffer:
you should see the background of the current line change as you move,
and also help-echo-like messages in the echo area for each non-empty
line in the buffer that follows an empty line.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 8:31 ` Thomas Dickey
2014-06-04 9:10 ` Thomas Dickey
@ 2014-06-04 13:06 ` Stefan Monnier
2014-06-04 20:26 ` Thomas Dickey
1 sibling, 1 reply; 70+ messages in thread
From: Stefan Monnier @ 2014-06-04 13:06 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
>> > 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.
>> I do not understand what that means. By "cursor-key sequence of
>> characters" do you mean the escape sequence sent by the terminal to
>> Emacs or the cursor-motion escape sequences sent from Emacs to the
>> text terminal?
> From the terminal to Emacs.
> Cursor up typically is
> ESC [ A
> three characters.
But that's a completely different problem from the one
we're investigating. The problem is about how the terminal emulator
reacts to Emacs's output, not how Emacs reacts to the terminal
emulator's output.
> Curses applications behave differently if you type those
> three characters, one-by-one, because of timing.
We try pretty hard to avoid using such timeouts in Emacs, so by and
large this doesn't apply to Emacs at all.
> That's part of it. Usually the input (from the terminal to the application)
> is more important.
But the present bug-report is about the other case.
To repeat the problem:
- a particular run of Emacs sends bytes <typescript> to the terminal
emulator, and the result doesn't look right.
- yet when we replay the same <typescript> directly to the terminal, the
result looks correct.
Note also that (other than the display), the state of Emacs at the end
of the test is correct (and forcing a redisplay indeed fixes the
display), so the problem is not in Emacs misinterpreting input because
of timing issues.
Stefan
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 10:16 ` Eli Zaretskii
@ 2014-06-04 16:08 ` Glenn Morris
2014-06-04 16:15 ` Eli Zaretskii
0 siblings, 1 reply; 70+ messages in thread
From: Glenn Morris @ 2014-06-04 16:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, dickey
Eli Zaretskii wrote:
> Here's a simple recipe to generate screen updates very similar to the
> ones caused by a menu update. Do they cause similar artifacts on the
> offending terminal emulators?
Not for me, no.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 9:38 ` Eli Zaretskii
2014-06-04 10:16 ` Eli Zaretskii
@ 2014-06-04 16:09 ` Glenn Morris
2014-06-04 16:23 ` Eli Zaretskii
2014-06-04 17:10 ` Eli Zaretskii
1 sibling, 2 replies; 70+ messages in thread
From: Glenn Morris @ 2014-06-04 16:09 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 17497, Thomas Dickey
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Eli Zaretskii wrote:
> On the hunch that the problems discussed here are caused by excess
> movement of the cursor, I've made changes in revision 117203 on the
> emacs-24 branch to avoid some of them. Please try that.
Sorry, still glitches. :(
[-- Attachment #2: 1.png --]
[-- Type: image/png, Size: 32194 bytes --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 16:08 ` Glenn Morris
@ 2014-06-04 16:15 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 16:15 UTC (permalink / raw
To: Glenn Morris; +Cc: 17497, dickey
> From: Glenn Morris <rgm@gnu.org>
> Cc: dickey@his.com, Stefan Monnier <monnier@iro.umontreal.ca>, 17497@debbugs.gnu.org
> Date: Wed, 04 Jun 2014 12:08:47 -0400
>
> Eli Zaretskii wrote:
>
> > Here's a simple recipe to generate screen updates very similar to the
> > ones caused by a menu update. Do they cause similar artifacts on the
> > offending terminal emulators?
>
> Not for me, no.
As expected. Thanks for testing.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 16:09 ` Glenn Morris
@ 2014-06-04 16:23 ` Eli Zaretskii
2014-06-04 17:10 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 16:23 UTC (permalink / raw
To: Glenn Morris; +Cc: 17497, dickey
> From: Glenn Morris <rgm@gnu.org>
> Cc: Thomas Dickey <dickey@his.com>, monnier@iro.umontreal.ca, 17497@debbugs.gnu.org
> Date: Wed, 04 Jun 2014 12:09:26 -0400
>
> > On the hunch that the problems discussed here are caused by excess
> > movement of the cursor, I've made changes in revision 117203 on the
> > emacs-24 branch to avoid some of them. Please try that.
>
> Sorry, still glitches. :(
Not surprisingly.
It still happens because these 3 lines:
--
Quit C-x C-c
Save unsaved buffers, then exit
were written starting from cursor position at the EOB of *scratch*,
instead of way below, on the line below the "Delete Frame" item. IOW,
some cursor motion commands emitted by Emacs are not obeyed for some
reason.
Thanks.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 16:09 ` Glenn Morris
2014-06-04 16:23 ` Eli Zaretskii
@ 2014-06-04 17:10 ` Eli Zaretskii
1 sibling, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-04 17:10 UTC (permalink / raw
To: Glenn Morris; +Cc: 17497, dickey
> From: Glenn Morris <rgm@gnu.org>
> Cc: Thomas Dickey <dickey@his.com>, monnier@iro.umontreal.ca, 17497@debbugs.gnu.org
> Date: Wed, 04 Jun 2014 12:09:26 -0400
>
> Eli Zaretskii wrote:
>
> > On the hunch that the problems discussed here are caused by excess
> > movement of the cursor, I've made changes in revision 117203 on the
> > emacs-24 branch to avoid some of them. Please try that.
>
> Sorry, still glitches. :(
If you put a breakpoint in update_frame and in update_frame_with_menu,
like shown below, how many calls do you see when you press an arrow
key (or C-n/C-p) that produces a glitch? I expect 1 call to
update_frame_with_menu followed by one call to update_frame. Here's a
GDB session on fencepost to show what I see:
(gdb) break update_frame
Breakpoint 1 at 0x41b605: file dispnew.c, line 3006.
(gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>continue
>end
(gdb) break update_frame_with_menu
Breakpoint 2 at 0x41b81b: file dispnew.c, line 3112.
(gdb) commands
Type commands for breakpoint(s) 4, one per line.
End with a line saying just "end".
>continue
>end
(gdb) c
Continuing.
Breakpoint 1, update_frame (f=0xd3e808, force_p=false,
inhibit_hairy_id_p=false) at dispnew.c:3006
3006 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=-1, col=-1)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=0, col=0)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=1, col=0)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
at dispnew.c:3006
3006 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=2, col=0)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
at dispnew.c:3006
3006 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=3, col=0)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
at dispnew.c:3006
3006 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=2, col=0)
at dispnew.c:3112
3112 struct window *root_window = XWINDOW (f->root_window);
Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
at dispnew.c:3006
3006 struct window *root_window = XWINDOW (f->root_window);
Explanations:
. first, a call to update_frame is because menu-bar-open calls
'redisplay'
. next, a call to update_frame_with_menu which comes from
the beginning of tty_menu_activate, line 3230 of term.c
. another call to update_frame_with_menu, to display the "File >"
header of the File menu.
. yet another call to update_frame_with_menu to display the first
menu item (Visit New File) in red background
. finally, a call to update_frame to display the help-echo for "Visit
New File"
Thereafter, for each keypress of an arrow key, there's always 1 call
to update_frame_with_menu, to display a different menu item in the red
background (see the values of row and col arguments, which identify
the menu item), followed by a single call to update_frame to display
the help echo.
Do you see any calls to update_frame beyond what I described? If so,
perhaps they are the reason the cursor gets back to the EOB of the
underlying buffer.
TIA
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 13:06 ` Stefan Monnier
@ 2014-06-04 20:26 ` Thomas Dickey
2014-06-05 0:47 ` Stefan Monnier
0 siblings, 1 reply; 70+ messages in thread
From: Thomas Dickey @ 2014-06-04 20:26 UTC (permalink / raw
To: Stefan Monnier; +Cc: 17497, Thomas Dickey
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Wed, Jun 04, 2014 at 09:06:11AM -0400, Stefan Monnier wrote:
> > Curses applications behave differently if you type those
> > three characters, one-by-one, because of timing.
>
> We try pretty hard to avoid using such timeouts in Emacs, so by and
> large this doesn't apply to Emacs at all.
As it happens, that rule of thumb doesn't apply to terminals:
https://github.com/mirrors/emacs/blob/master/src/keyboard.c
(it's implemented there, at any rate)
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-04 20:26 ` Thomas Dickey
@ 2014-06-05 0:47 ` Stefan Monnier
2014-06-05 8:21 ` Thomas Dickey
0 siblings, 1 reply; 70+ messages in thread
From: Stefan Monnier @ 2014-06-05 0:47 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
>> > Curses applications behave differently if you type those
>> > three characters, one-by-one, because of timing.
>> We try pretty hard to avoid using such timeouts in Emacs, so by and
>> large this doesn't apply to Emacs at all.
> As it happens, that rule of thumb doesn't apply to terminals:
> https://github.com/mirrors/emacs/blob/master/src/keyboard.c
> (it's implemented there, at any rate)
Where do you see the timeouts?
Or rather, no, don't bother, because even there might be problem in how
we process the input escape sequences, these are unrelated to the
display glitches we see. So let's focus on the display glitches.
Stefan
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 0:47 ` Stefan Monnier
@ 2014-06-05 8:21 ` Thomas Dickey
2014-06-05 8:29 ` Andreas Schwab
` (3 more replies)
0 siblings, 4 replies; 70+ messages in thread
From: Thomas Dickey @ 2014-06-05 8:21 UTC (permalink / raw
To: Stefan Monnier; +Cc: 17497, Thomas Dickey
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
On Wed, Jun 04, 2014 at 08:47:42PM -0400, Stefan Monnier wrote:
> >> > Curses applications behave differently if you type those
> >> > three characters, one-by-one, because of timing.
> >> We try pretty hard to avoid using such timeouts in Emacs, so by and
> >> large this doesn't apply to Emacs at all.
> > As it happens, that rule of thumb doesn't apply to terminals:
> > https://github.com/mirrors/emacs/blob/master/src/keyboard.c
> > (it's implemented there, at any rate)
>
> Where do you see the timeouts?
start with
static bool get_input_pending (int);
The code's waiting for a while to ensure that it gets all of the bytes in
a cursor-key/function-key/mouse-event sequence.
> Or rather, no, don't bother, because even there might be problem in how
> we process the input escape sequences, these are unrelated to the
> display glitches we see. So let's focus on the display glitches.
You could cut the discussion short by making the check that I suggested:
logging the decoded character/special-key values to look for instances
where the decoding returns individual bytes.
--
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 --]
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 8:21 ` Thomas Dickey
@ 2014-06-05 8:29 ` Andreas Schwab
2014-06-05 15:02 ` Eli Zaretskii
2014-06-05 13:44 ` Stefan Monnier
` (2 subsequent siblings)
3 siblings, 1 reply; 70+ messages in thread
From: Andreas Schwab @ 2014-06-05 8:29 UTC (permalink / raw
To: dickey; +Cc: 17497
Thomas Dickey <dickey@his.com> writes:
> start with
> static bool get_input_pending (int);
>
> The code's waiting for a while to ensure that it gets all of the bytes in
> a cursor-key/function-key/mouse-event sequence.
No, it doesn't. It just reads whatever is pending, without paying
attention to key boundaries.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 8:21 ` Thomas Dickey
2014-06-05 8:29 ` Andreas Schwab
@ 2014-06-05 13:44 ` Stefan Monnier
2014-06-05 13:47 ` Stefan Monnier
2014-06-05 15:00 ` Eli Zaretskii
3 siblings, 0 replies; 70+ messages in thread
From: Stefan Monnier @ 2014-06-05 13:44 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
> You could cut the discussion short by making the check that I suggested:
> logging the decoded character/special-key values to look for instances
> where the decoding returns individual bytes.
No we cut it short by noticing that Emacs's internal state is the one we
expect and the display is completely wrong, which is something that
cannot happen due to some weird input sequence.
Please believe us, we *really* know that the problem is not in Emacs's
misunderstanding/misdecoding of the input stream (yes, it does have
bugs there, of course, but they're unrelated).
To repeat: replaying the termscript results in a different display (not
only that, it results in the display we want)!
This can't be due to Emacs's input processing.
Stefan
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 8:21 ` Thomas Dickey
2014-06-05 8:29 ` Andreas Schwab
2014-06-05 13:44 ` Stefan Monnier
@ 2014-06-05 13:47 ` Stefan Monnier
2014-06-05 15:00 ` Eli Zaretskii
3 siblings, 0 replies; 70+ messages in thread
From: Stefan Monnier @ 2014-06-05 13:47 UTC (permalink / raw
To: Thomas Dickey; +Cc: 17497
> The code's waiting for a while to ensure that it gets all of the bytes in
> a cursor-key/function-key/mouse-event sequence.
No, it's not. Try it:
emacs -Q -nw
then hit ESC O A on your keyboard.
Feel free to type those three keys real slow, or real fast. It makes
little difference.
Stefan
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 8:21 ` Thomas Dickey
` (2 preceding siblings ...)
2014-06-05 13:47 ` Stefan Monnier
@ 2014-06-05 15:00 ` Eli Zaretskii
3 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-05 15:00 UTC (permalink / raw
To: dickey; +Cc: 17497, dickey
> Date: Thu, 05 Jun 2014 04:21:51 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: Thomas Dickey <dickey@his.com>, 17497@debbugs.gnu.org,
> Eli Zaretskii <eliz@gnu.org>
>
> > Or rather, no, don't bother, because even there might be problem in how
> > we process the input escape sequences, these are unrelated to the
> > display glitches we see. So let's focus on the display glitches.
>
> You could cut the discussion short by making the check that I suggested:
> logging the decoded character/special-key values to look for instances
> where the decoding returns individual bytes.
I don't think this is the problem in this case. The arrow keys are
clearly decoded correctly and obeyed, as we see the reaction to them,
which is to redraw certain portions of the screen. It's not like an
arrow key we get from the keyboard is sent verbatim to the terminal;
rather, Emacs interprets that key as a command to change the
background of two screen lines, and then sends the related commands,
including cursor motion, to the terminal. IOW, the cursor motion
commands sent to the terminal are not what we receive from the
keyboard, they are generated by Emacs using a non-trivial logic in
cmgoto (which could decide that it is better to send a single newline
character, if it needs to move down just one line, or move to the
upper-left corner of the screen, for example).
Moreover, using C-n and C-p, which are single bytes, doesn't make the
problem go away.
So some other factor is at work here. Keyboard input is unrelated,
at least as far as Emacs's code is concerned.
^ permalink raw reply [flat|nested] 70+ messages in thread
* bug#17497: 24.4.50; TTY menu glitches
2014-06-05 8:29 ` Andreas Schwab
@ 2014-06-05 15:02 ` Eli Zaretskii
0 siblings, 0 replies; 70+ messages in thread
From: Eli Zaretskii @ 2014-06-05 15:02 UTC (permalink / raw
To: Andreas Schwab; +Cc: 17497, dickey
> From: Andreas Schwab <schwab@suse.de>
> Date: Thu, 05 Jun 2014 10:29:14 +0200
> Cc: 17497@debbugs.gnu.org
>
> Thomas Dickey <dickey@his.com> writes:
>
> > start with
> > static bool get_input_pending (int);
> >
> > The code's waiting for a while to ensure that it gets all of the bytes in
> > a cursor-key/function-key/mouse-event sequence.
>
> No, it doesn't. It just reads whatever is pending, without paying
> attention to key boundaries.
In addition, the function which reads keys isn't called during menu
updates, because we call update_frame_1 with its argument force_p
non-zero, so update_frame_1 doesn't even pay attention whether there's
input available.
^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2014-06-05 15:02 UTC | newest]
Thread overview: 70+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <83vbslbuqr.fsf@gnu.org>
[not found] ` <20140531200947.GA779@aerie.jexium-island.net>
[not found] ` <83lhtgbrd6.fsf@gnu.org>
[not found] ` <20140601152657.GA15078@aerie.jexium-island.net>
2014-06-01 16:25 ` bug#17497: 24.4.50; TTY menu glitches Eli Zaretskii
2014-06-01 17:12 ` Thomas Dickey
2014-06-01 17:18 ` Thomas Dickey
2014-06-01 18:45 ` Eli Zaretskii
2014-06-01 19:46 ` Thomas Dickey
2014-06-02 15:17 ` Eli Zaretskii
2014-06-02 16:14 ` Glenn Morris
2014-06-02 16:43 ` Eli Zaretskii
2014-06-02 16:46 ` Glenn Morris
2014-06-02 16:56 ` Eli Zaretskii
2014-06-02 17:05 ` Glenn Morris
2014-06-03 13:43 ` Stefan Monnier
2014-06-03 18:47 ` Thomas Dickey
2014-06-03 21:07 ` Eli Zaretskii
2014-06-03 22:21 ` Thomas Dickey
2014-06-04 6:54 ` Eli Zaretskii
2014-06-04 3:03 ` Stefan Monnier
2014-06-04 8:31 ` Thomas Dickey
2014-06-04 9:10 ` Thomas Dickey
2014-06-04 9:38 ` Eli Zaretskii
2014-06-04 10:16 ` Eli Zaretskii
2014-06-04 16:08 ` Glenn Morris
2014-06-04 16:15 ` Eli Zaretskii
2014-06-04 16:09 ` Glenn Morris
2014-06-04 16:23 ` Eli Zaretskii
2014-06-04 17:10 ` Eli Zaretskii
2014-06-04 13:06 ` Stefan Monnier
2014-06-04 20:26 ` Thomas Dickey
2014-06-05 0:47 ` Stefan Monnier
2014-06-05 8:21 ` Thomas Dickey
2014-06-05 8:29 ` Andreas Schwab
2014-06-05 15:02 ` Eli Zaretskii
2014-06-05 13:44 ` Stefan Monnier
2014-06-05 13:47 ` Stefan Monnier
2014-06-05 15:00 ` Eli Zaretskii
2014-06-01 18:39 ` Eli Zaretskii
2014-05-15 12:26 Dmitry Antipov
2014-05-15 17:37 ` Eli Zaretskii
2014-05-16 6:36 ` Glenn Morris
2014-05-16 6:38 ` Glenn Morris
2014-05-16 6:53 ` Glenn Morris
2014-05-16 8:48 ` Eli Zaretskii
2014-05-16 15:47 ` Glenn Morris
2014-05-16 20:21 ` Eli Zaretskii
2014-05-17 9:56 ` Eli Zaretskii
2014-05-22 2:49 ` Eli Zaretskii
2014-05-22 5:44 ` Glenn Morris
2014-05-22 7:51 ` Andreas Schwab
2014-05-22 15:58 ` Glenn Morris
2014-05-22 17:19 ` Andreas Schwab
2014-05-22 17:29 ` Glenn Morris
2014-05-22 17:53 ` Eli Zaretskii
2014-05-22 16:19 ` Eli Zaretskii
2014-05-22 16:26 ` Glenn Morris
2014-05-22 16:46 ` Eli Zaretskii
2014-05-30 9:22 ` Eli Zaretskii
2014-05-31 2:22 ` Glenn Morris
2014-05-31 8:20 ` Eli Zaretskii
2014-05-31 17:35 ` Glenn Morris
2014-06-01 15:11 ` Eli Zaretskii
2014-06-03 4:51 ` Glenn Morris
2014-06-03 7:03 ` Eli Zaretskii
2014-05-22 16:43 ` Eli Zaretskii
2014-05-22 16:54 ` Glenn Morris
2014-05-22 17:07 ` Eli Zaretskii
2014-05-16 9:42 ` Dmitry Antipov
2014-05-16 10:26 ` Eli Zaretskii
2014-05-16 10:46 ` Eli Zaretskii
2014-05-16 14:59 ` Dmitry Antipov
2014-05-16 15:26 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.