bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Tom Levy]

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))

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Eli Zaretskii]

> 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?

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Tom Levy]

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?

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Eli Zaretskii]

> 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.

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Eli Zaretskii]

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?

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Alan Mackenzie]

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).

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Tom Levy]

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?

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Eli Zaretskii]

> 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.

bug#38016: 27.0.50; Display issues with delay-warning and side-by-side windows in terminal

[Eli Zaretskii]

> 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?