* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
@ 2019-11-01 5:11 Tom Levy
2019-11-01 7:06 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Tom Levy @ 2019-11-01 5:11 UTC (permalink / raw)
To: 38016
Steps:
Maximize a terminal window to make Emacs use a side-by-side window split.
Run: emacs -Q -nw --eval '(delay-warning :debug "line 1\nline 2")'
The *scratch* and *Warnings* buffers should be displayed side by side.
Press M-< C-e RET DEL (in the *scratch* buffer).
Line 2 in the *Warnings* buffer disappears (!)
Variation: run Emacs as before, but press M-< C-e a RET
Line 2 in the *Warnings* buffer moves down (!)
Happens in master (27.0.50) and 24.5.1, with both gnome-terminal and
xterm.
In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
of 2019-11-01 built on localhost
Repository revision: 9d209c90345df6c39310912ba04ca02473a24bed
Repository branch: master
System Description: Debian GNU/Linux 10 (buster)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER
LCMS2 GMP
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
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-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
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils warnings term/xterm xterm
byte-opt gv bytecomp byte-compile cconv tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded 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 threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 48787 4146)
(symbols 48 6105 1)
(strings 32 15685 1644)
(string-bytes 1 503280)
(vectors 16 7236)
(vector-slots 8 77463 6914)
(floats 8 23 379)
(intervals 56 182 0)
(buffers 1000 12))
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 5:11 bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal Tom Levy
@ 2019-11-01 7:06 ` Eli Zaretskii
2019-11-01 7:39 ` Tom Levy
[not found] ` <mailman.162.1572592024.13325.bug-gnu-emacs@gnu.org>
0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2019-11-01 7:06 UTC (permalink / raw)
To: Tom Levy; +Cc: 38016
> From: Tom Levy <tomlevy93@gmail.com>
> Date: Fri, 01 Nov 2019 18:11:45 +1300
>
> Maximize a terminal window to make Emacs use a side-by-side window split.
> Run: emacs -Q -nw --eval '(delay-warning :debug "line 1\nline 2")'
> The *scratch* and *Warnings* buffers should be displayed side by side.
> Press M-< C-e RET DEL (in the *scratch* buffer).
> Line 2 in the *Warnings* buffer disappears (!)
>
> Variation: run Emacs as before, but press M-< C-e a RET
> Line 2 in the *Warnings* buffer moves down (!)
>
> Happens in master (27.0.50) and 24.5.1, with both gnome-terminal and
> xterm.
I couldn't reproduce this, neither on GNU/Linux nor on MS-Windows.
Can anyone else reproduce this?
Does the "disappearing" and "moving" text really disappear and move?
What happens if you invoke "M-x redraw-display RET" after your recipe:
does the display return to be as expected?
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 7:06 ` Eli Zaretskii
@ 2019-11-01 7:39 ` Tom Levy
2019-11-01 7:46 ` Eli Zaretskii
[not found] ` <mailman.162.1572592024.13325.bug-gnu-emacs@gnu.org>
1 sibling, 1 reply; 9+ messages in thread
From: Tom Levy @ 2019-11-01 7:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38016
Thanks for taking a look. The lines don't really change, "M-x
redraw-display RET" returns the display to the expected state.*
It happens for me on Debian 9.11 and 10 (in a clean VM), should I try
another OS?
* Just pressing "M-x" changes the display. With the first variation
(i.e. ... C-e RET DEL M-x) it returns the display to the expected state.
With the second variation (i.e. ... C-e a RET M-x) it correctly displays
"line 2" on the second line, but doesn't clear the third line; when I
continue with "redraw-display RET" the third line is cleared, returning
the display to the expected state.
On Fri, 1 Nov 2019 at 20:06, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Tom Levy <tomlevy93@gmail.com>
> > Date: Fri, 01 Nov 2019 18:11:45 +1300
> >
> > Maximize a terminal window to make Emacs use a side-by-side window split.
> > Run: emacs -Q -nw --eval '(delay-warning :debug "line 1\nline 2")'
> > The *scratch* and *Warnings* buffers should be displayed side by side.
> > Press M-< C-e RET DEL (in the *scratch* buffer).
> > Line 2 in the *Warnings* buffer disappears (!)
> >
> > Variation: run Emacs as before, but press M-< C-e a RET
> > Line 2 in the *Warnings* buffer moves down (!)
> >
> > Happens in master (27.0.50) and 24.5.1, with both gnome-terminal and
> > xterm.
>
> I couldn't reproduce this, neither on GNU/Linux nor on MS-Windows.
> Can anyone else reproduce this?
>
> Does the "disappearing" and "moving" text really disappear and move?
> What happens if you invoke "M-x redraw-display RET" after your recipe:
> does the display return to be as expected?
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 7:39 ` Tom Levy
@ 2019-11-01 7:46 ` Eli Zaretskii
2019-11-01 9:50 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-11-01 7:46 UTC (permalink / raw)
To: Tom Levy; +Cc: 38016
> From: Tom Levy <tomlevy93@gmail.com>
> Date: Fri, 1 Nov 2019 20:39:38 +1300
> Cc: 38016@debbugs.gnu.org
>
> Thanks for taking a look. The lines don't really change, "M-x
> redraw-display RET" returns the display to the expected state.*
>
> It happens for me on Debian 9.11 and 10 (in a clean VM), should I try
> another OS?
>
>
> * Just pressing "M-x" changes the display. With the first variation
> (i.e. ... C-e RET DEL M-x) it returns the display to the expected state.
> With the second variation (i.e. ... C-e a RET M-x) it correctly displays
> "line 2" on the second line, but doesn't clear the third line; when I
> continue with "redraw-display RET" the third line is cleared, returning
> the display to the expected state.
Let's see if someone else can reproduce this. It could be related to
the terminal emulator, not to the OS.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 7:46 ` Eli Zaretskii
@ 2019-11-01 9:50 ` Eli Zaretskii
2019-11-01 12:29 ` Tom Levy
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-11-01 9:50 UTC (permalink / raw)
To: tomlevy93; +Cc: 38016
Btw, if you do NOT make the terminal full-screen, and instead modify
the Emacs invocation command like this:
emacs -Q -nw --eval '(progn (setq split-height-threshold 80) (setq split-width-threshold 20) (display-warning :debug "lin 1\nline 2"))'
do you still see the problem?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 9:50 ` Eli Zaretskii
@ 2019-11-01 12:29 ` Tom Levy
2019-11-01 13:13 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Tom Levy @ 2019-11-01 12:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38016
Note: the problem occurs with DELAY-warning, not display-warning.
The results of
emacs -Q -nw --eval '(progn (setq split-height-threshold 80) (setq
split-width-threshold 20) (delay-warning :debug "line 1\nline 2"))'
depend on the terminal size. There is a definite pattern where the
glitch occurs in the larger sizes, but the precise rule is not obvious.
With the default size (LINES=24, COLUMNS=80) the glitch does not occur.
But truncate-partial-width-windows is in effect. Also, from experiments
it makes a difference if the lines in the *scratch* buffer are wrapped.
To reduce complexity from line wrapping, I used the following command:
emacs -Q -nw --eval '(progn
(setq truncate-partial-width-windows nil)
(setq initial-scratch-message ";; short\n;; message\n\n")
(setq split-height-threshold 80)
(setq split-width-threshold 20)
(delay-warning :debug "line 1\nline 2"))'
Results:
$LINES first value of $COLUMNS with glitch
18 155
19 149
24 129
37 99
48 89
So for example when LINES=24, the glitch occurs if COLUMNS >= 129 and
does not occur if COLUMNS <= 128. (I haven't actually tried all the
values, but the rule works for all those that I did try.)
On Fri, 1 Nov 2019 at 22:50, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Btw, if you do NOT make the terminal full-screen, and instead modify
> the Emacs invocation command like this:
>
> emacs -Q -nw --eval '(progn (setq split-height-threshold 80) (setq split-width-threshold 20) (display-warning :debug "lin 1\nline 2"))'
>
> do you still see the problem?
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 12:29 ` Tom Levy
@ 2019-11-01 13:13 ` Eli Zaretskii
2019-11-01 15:57 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-11-01 13:13 UTC (permalink / raw)
To: Tom Levy; +Cc: 38016
> From: Tom Levy <tomlevy93@gmail.com>
> Date: Sat, 2 Nov 2019 01:29:22 +1300
> Cc: 38016@debbugs.gnu.org
>
> emacs -Q -nw --eval '(progn
> (setq truncate-partial-width-windows nil)
> (setq initial-scratch-message ";; short\n;; message\n\n")
> (setq split-height-threshold 80)
> (setq split-width-threshold 20)
> (delay-warning :debug "line 1\nline 2"))'
>
> Results:
>
> $LINES first value of $COLUMNS with glitch
> 18 155
> 19 149
> 24 129
> 37 99
> 48 89
Thanks, now I see this and will look into it when I have time.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
2019-11-01 13:13 ` Eli Zaretskii
@ 2019-11-01 15:57 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2019-11-01 15:57 UTC (permalink / raw)
To: tomlevy93; +Cc: 38016
> Date: Fri, 01 Nov 2019 15:13:00 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 38016@debbugs.gnu.org
>
> > From: Tom Levy <tomlevy93@gmail.com>
> > Date: Sat, 2 Nov 2019 01:29:22 +1300
> > Cc: 38016@debbugs.gnu.org
> >
> > emacs -Q -nw --eval '(progn
> > (setq truncate-partial-width-windows nil)
> > (setq initial-scratch-message ";; short\n;; message\n\n")
> > (setq split-height-threshold 80)
> > (setq split-width-threshold 20)
> > (delay-warning :debug "line 1\nline 2"))'
> >
> > Results:
> >
> > $LINES first value of $COLUMNS with glitch
> > 18 155
> > 19 149
> > 24 129
> > 37 99
> > 48 89
>
> Thanks, now I see this and will look into it when I have time.
Looks like some weird problem with cursor motion commands Emacs emits
on a TTY. As screen dimension change, Emacs tries to optimize the
commands it sends, and changes the commands it emits to put the cursor
at given display coordinates, see cm.c:cmgoto. Probably related to
bug#24124 (which remains unresolved).
The way to record the commands Emacs sends to the terminal is to
invoke open-termscript. The commands will be in the file this
function gets as its 2nd argument.
We need a terminfo expert to find out what's wrong here. Anyone?
^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <mailman.162.1572592024.13325.bug-gnu-emacs@gnu.org>]
* bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal
[not found] ` <mailman.162.1572592024.13325.bug-gnu-emacs@gnu.org>
@ 2019-11-01 10:20 ` Alan Mackenzie
0 siblings, 0 replies; 9+ messages in thread
From: Alan Mackenzie @ 2019-11-01 10:20 UTC (permalink / raw)
To: gnu-emacs-bug
Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Tom Levy <tomlevy93@gmail.com>
>> Date: Fri, 01 Nov 2019 18:11:45 +1300
>> Maximize a terminal window to make Emacs use a side-by-side window split.
>> Run: emacs -Q -nw --eval '(delay-warning :debug "line 1\nline 2")'
>> The *scratch* and *Warnings* buffers should be displayed side by side.
>> Press M-< C-e RET DEL (in the *scratch* buffer).
>> Line 2 in the *Warnings* buffer disappears (!)
>> Variation: run Emacs as before, but press M-< C-e a RET
>> Line 2 in the *Warnings* buffer moves down (!)
>> Happens in master (27.0.50) and 24.5.1, with both gnome-terminal and
>> xterm.
> I couldn't reproduce this, neither on GNU/Linux nor on MS-Windows.
> Can anyone else reproduce this?
I see this on a Linux tty (started without the -nw argument).
> Does the "disappearing" and "moving" text really disappear and move?
> What happens if you invoke "M-x redraw-display RET" after your recipe:
> does the display return to be as expected?
Well, from the *scratch* buffer I did C-x o to move to the *warnings*
buffer, and Line 2 reappeared.
On M-x redraw-display (immediately after the DEL), Line 2 reappears
instantly after M-x. Completing the redraw-display doesn't further
change what is displayed.
I'm running on Emacs master, though it's been a few days since I updated
it.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-01 15:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-01 5:11 bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal Tom Levy
2019-11-01 7:06 ` Eli Zaretskii
2019-11-01 7:39 ` Tom Levy
2019-11-01 7:46 ` Eli Zaretskii
2019-11-01 9:50 ` Eli Zaretskii
2019-11-01 12:29 ` Tom Levy
2019-11-01 13:13 ` Eli Zaretskii
2019-11-01 15:57 ` Eli Zaretskii
[not found] ` <mailman.162.1572592024.13325.bug-gnu-emacs@gnu.org>
2019-11-01 10:20 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).