bug#25666: Screen rendering bug

bug#25666: Screen rendering bug

[Fredrik Ljungdahl]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Hi.
I encountered a minor bug related to screen rendering in vertical split
screen (a | b) of the same file and some forms of page scrolling. The
problem seems to be related to linum-mode.

What I did to reproduce this bug under default settings:
* I used a 146x46 size terminal (potentially matters)
* Acquire this: http://sprunge.us/hVNi
* Invoke emacs with emacs -Q
* Go to this file (C-x C-f hVNi)
* Invoke line number mode (M-x linum-mode), lack of linum-mode doesn't seem
to reproduce this
* Split the window (C-x 3)
* Hold down C-n (C-v does not reproduce this)
* On the 2nd half-scroll, the 2nd split window should have its rendering
messed up in obvious ways

Emacs version: 25.1.1
System info (uname -a): Linux fiq-desktop 4.9.6-1-ARCH #1 SMP PREEMPT Thu
Jan 26 09:22:26 CET 2017 x86_64 GNU/Linux
I am using the terminal version of Emacs

Regards
FIQ

[-- Attachment #2: Type: text/html, Size: 1117 bytes --]

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: Fredrik Ljungdahl <fredde1994@gmail.com>
> Date: Thu, 9 Feb 2017 09:23:48 +0100
> 
> * I used a 146x46 size terminal (potentially matters)
> * Acquire this: http://sprunge.us/hVNi
> * Invoke emacs with emacs -Q
> * Go to this file (C-x C-f hVNi)
> * Invoke line number mode (M-x linum-mode), lack of linum-mode doesn't seem to reproduce this
> * Split the window (C-x 3)
> * Hold down C-n (C-v does not reproduce this)
> * On the 2nd half-scroll, the 2nd split window should have its rendering messed up in obvious ways

I did this, and didn't see any messup.

bug#25666: Screen rendering bug

[Fredrik Ljungdahl]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

I attempted to reproduce this in a different terminal, in case that was the
issue (I originally used Konsole), in this case xterm. I was not able to
reproduce under the standard resolution of 80x24. However, by increasing
the resolution by fullscreening it (resulting in a terminal size of
212x78), I was able to once again reproducue the bug. Further testing shows
that, with that particular file, I am able to reproduce the issue in 116x24
but not 80x24. I am guessing that text wrapping is involved in some way,
but I can't consistently figure out where the bug reproduces and when it
doesn't (aside from it always or never reproducing under the same terminal
size).

/FIQ

2017-02-09 21:37 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fredrik Ljungdahl <fredde1994@gmail.com>
> > Date: Thu, 9 Feb 2017 09:23:48 +0100
> >
> > * I used a 146x46 size terminal (potentially matters)
> > * Acquire this: http://sprunge.us/hVNi
> > * Invoke emacs with emacs -Q
> > * Go to this file (C-x C-f hVNi)
> > * Invoke line number mode (M-x linum-mode), lack of linum-mode doesn't
> seem to reproduce this
> > * Split the window (C-x 3)
> > * Hold down C-n (C-v does not reproduce this)
> > * On the 2nd half-scroll, the 2nd split window should have its rendering
> messed up in obvious ways
>
> I did this, and didn't see any messup.
>

[-- Attachment #2: Type: text/html, Size: 1845 bytes --]

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: Fredrik Ljungdahl <fredde1994@gmail.com>
> Date: Thu, 9 Feb 2017 22:37:47 +0100
> Cc: 25666@debbugs.gnu.org
> 
> I attempted to reproduce this in a different terminal, in case that was the issue (I originally used Konsole), in
> this case xterm. I was not able to reproduce under the standard resolution of 80x24. However, by increasing
> the resolution by fullscreening it (resulting in a terminal size of 212x78), I was able to once again reproducue
> the bug. Further testing shows that, with that particular file, I am able to reproduce the issue in 116x24 but not
> 80x24. I am guessing that text wrapping is involved in some way, but I can't consistently figure out where the
> bug reproduces and when it doesn't (aside from it always or never reproducing under the same terminal
> size).

Please show a screenshot of the messup you see.

Thanks.

bug#25666: Screen rendering bug

[Fredrik Ljungdahl]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

Hi.
Here is a screenshot: http://home.fiq.se/emacsfail.png
This is in my personal Emacs environment, but it shows the same way in the
default one. Note the right screen (And no, that isn't the end of the file)

/FIQ

2017-02-10 9:29 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fredrik Ljungdahl <fredde1994@gmail.com>
> > Date: Thu, 9 Feb 2017 22:37:47 +0100
> > Cc: 25666@debbugs.gnu.org
> >
> > I attempted to reproduce this in a different terminal, in case that was
> the issue (I originally used Konsole), in
> > this case xterm. I was not able to reproduce under the standard
> resolution of 80x24. However, by increasing
> > the resolution by fullscreening it (resulting in a terminal size of
> 212x78), I was able to once again reproducue
> > the bug. Further testing shows that, with that particular file, I am
> able to reproduce the issue in 116x24 but not
> > 80x24. I am guessing that text wrapping is involved in some way, but I
> can't consistently figure out where the
> > bug reproduces and when it doesn't (aside from it always or never
> reproducing under the same terminal
> > size).
>
> Please show a screenshot of the messup you see.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1746 bytes --]

bug#25666: Screen rendering bug

[Fredrik Ljungdahl]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

I just tried on another computer as well which has emacs 24.5.1 and using
gnome-terminal. It reproduces in the terminal, but not under Xemacs.

/FIQ

2017-02-10 10:12 GMT+01:00 Fredrik Ljungdahl <fredde1994@gmail.com>:

> Hi.
> Here is a screenshot: http://home.fiq.se/emacsfail.png
> This is in my personal Emacs environment, but it shows the same way in the
> default one. Note the right screen (And no, that isn't the end of the file)
>
> /FIQ
>
> 2017-02-10 9:29 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>
>> > From: Fredrik Ljungdahl <fredde1994@gmail.com>
>> > Date: Thu, 9 Feb 2017 22:37:47 +0100
>> > Cc: 25666@debbugs.gnu.org
>> >
>> > I attempted to reproduce this in a different terminal, in case that was
>> the issue (I originally used Konsole), in
>> > this case xterm. I was not able to reproduce under the standard
>> resolution of 80x24. However, by increasing
>> > the resolution by fullscreening it (resulting in a terminal size of
>> 212x78), I was able to once again reproducue
>> > the bug. Further testing shows that, with that particular file, I am
>> able to reproduce the issue in 116x24 but not
>> > 80x24. I am guessing that text wrapping is involved in some way, but I
>> can't consistently figure out where the
>> > bug reproduces and when it doesn't (aside from it always or never
>> reproducing under the same terminal
>> > size).
>>
>> Please show a screenshot of the messup you see.
>>
>> Thanks.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2377 bytes --]

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: Fredrik Ljungdahl <fredde1994@gmail.com>
> Date: Fri, 10 Feb 2017 10:12:31 +0100
> Cc: 25666@debbugs.gnu.org
> 
> Here is a screenshot: http://home.fiq.se/emacsfail.png
> This is in my personal Emacs environment, but it shows the same way in the default one. Note the right
> screen (And no, that isn't the end of the file)

So the problem is that the right-side window gets its contents
scrolled and its lower half emptied?  Or is there something else?

bug#25666: Screen rendering bug

[Fredrik Ljungdahl]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

Yes.

2017-02-10 11:22 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Fredrik Ljungdahl <fredde1994@gmail.com>
> > Date: Fri, 10 Feb 2017 10:12:31 +0100
> > Cc: 25666@debbugs.gnu.org
> >
> > Here is a screenshot: http://home.fiq.se/emacsfail.png
> > This is in my personal Emacs environment, but it shows the same way in
> the default one. Note the right
> > screen (And no, that isn't the end of the file)
>
> So the problem is that the right-side window gets its contents
> scrolled and its lower half emptied?  Or is there something else?
>

[-- Attachment #2: Type: text/html, Size: 1086 bytes --]

bug#25666: Screen rendering bug

[npostavs]

found 25666 24.4
found 25666 25.1
tags 25666 confirmed
retitle 25666 split-screen + linum-mode in tall TTY fails to fully render other window after scrolling
severity 25666 minor
quit

>  > From: Fredrik Ljungdahl <fredde1994@gmail.com>
>  > Date: Thu, 9 Feb 2017 09:23:48 +0100
>  >
>  > * I used a 146x46 size terminal (potentially matters)
>  > * Acquire this: http://sprunge.us/hVNi
>  > * Invoke emacs with emacs -Q
>  > * Go to this file (C-x C-f hVNi)
>  > * Invoke line number mode (M-x linum-mode), lack of linum-mode doesn't seem to reproduce this
>  > * Split the window (C-x 3)
>  > * Hold down C-n (C-v does not reproduce this)
>  > * On the 2nd half-scroll, the 2nd split window should have its rendering messed up in obvious ways

Fredrik Ljungdahl <fredde1994@gmail.com> writes:

> I attempted to reproduce this in a different terminal, in case that
> was the issue (I originally used Konsole), in this case xterm. I was
> not able to reproduce under the standard resolution of 80x24. However,
> by increasing the resolution by fullscreening it (resulting in a
> terminal size of 212x78), I was able to once again reproducue the
> bug. Further testing shows that, with that particular file, I am able
> to reproduce the issue in 116x24 but not 80x24. I am guessing that
> text wrapping is involved in some way, but I can't consistently figure
> out where the bug reproduces and when it doesn't (aside from it always
> or never reproducing under the same terminal size).

I can reproduce this.  Doing C-l fixes it, and I can't reproduce after
that until I delete and resplit the window.  My terminal is urxvt.

I can't reproduce in 24.3.

I notice that the `linum' face is rendered identically to the default
face in 24.4 and up.  Could be related.

It doesn't happen with nlinum-mode, probably because with nlinum-mode
when the left window scrolls, the margin in the right window is widened
too.

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: Eli Zaretskii <eliz@gnu.org>,  25666@debbugs.gnu.org
> Date: Sun, 12 Feb 2017 10:56:27 -0500
> 
> retitle 25666 split-screen + linum-mode in tall TTY fails to fully render other window after scrolling

That's not really accurate, see below.

> I can reproduce this.  Doing C-l fixes it, and I can't reproduce after
> that until I delete and resplit the window.  My terminal is urxvt.

I see the same here.  The frame dimensions are not relevant, btw: I
can see this with any dimensions I tried.  But it only happens on a
text terminal that uses terminfo/termcap; the MS-Windows text-mode
Emacs doesn't have this problem.

> I can't reproduce in 24.3.

Yes, it started in Emacs 24.4.

> I notice that the `linum' face is rendered identically to the default
> face in 24.4 and up.  Could be related.

My guess is it's unrelated.  But I don't really know.

> It doesn't happen with nlinum-mode, probably because with nlinum-mode
> when the left window scrolls, the margin in the right window is widened
> too.

I see this with nlinum-mode as well.  My terminal is PuTTY (which
emulates xterm).

You can also trigger a slightly different messup by "M-<" after the
first scroll (which by itself looks OK).

What happens is this: Emacs thinks the non-selected window is empty,
so it correctly decides that the best strategy to redisplay the
selected window is to scroll the entire frame half-height up, then
display the bottom part of the selected window from its buffer text.

Why it thinks the non-selected window is empty?  Here's where the plot
thickens.  The non-selected window doesn't need to be updated, so
Emacs correctly uses its "current" glyph matrix instead of the
"desired" matrix.  But the current matrix describes 35 empty lines.
It does that because on the first cursor motion after the previous
half-window scroll of the selected window, the desired matrix is
copied into the current one, and that "empties" the current matrix.
Not sure why the latter happens.

That is as far as I got debugging this.

I also found a work-around: invoke C-l or redraw-display immediately
after "C-x 3".  Then the problem never happens.  So this sounds like
some missing initialization, somewhere.

bug#25666: Screen rendering bug

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

> I see the same here.  The frame dimensions are not relevant, btw: I
> can see this with any dimensions I tried.

Hmm, like the OP, I can't reproduce with an 80x24 terminal.

>> It doesn't happen with nlinum-mode, probably because with nlinum-mode
>> when the left window scrolls, the margin in the right window is widened
>> too.
>
> I see this with nlinum-mode as well.  My terminal is PuTTY (which
> emulates xterm).

Ah, this depends on how high the terminal is.  With an 80x32 terminal I
see it with nlinum-mode as well.  I think it's just a question of
whether the first scroll reaches high enough line numbers to trigger a
margin width adjustment.

> You can also trigger a slightly different messup by "M-<" after the
> first scroll (which by itself looks OK).

Yes, in this case the top half of the other window gets lost.

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 25666@debbugs.gnu.org,  fredde1994@gmail.com
> Date: Sun, 12 Feb 2017 12:15:06 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I see the same here.  The frame dimensions are not relevant, btw: I
> > can see this with any dimensions I tried.
> 
> Hmm, like the OP, I can't reproduce with an 80x24 terminal.

I believe you because I didn't try with those dimensions ;-)
The OP started by saying that the frame should be _wider_ than 80
columns, and my assertion above should have been "the frame width is
not relevant".

> >> It doesn't happen with nlinum-mode, probably because with nlinum-mode
> >> when the left window scrolls, the margin in the right window is widened
> >> too.
> >
> > I see this with nlinum-mode as well.  My terminal is PuTTY (which
> > emulates xterm).
> 
> Ah, this depends on how high the terminal is.  With an 80x32 terminal I
> see it with nlinum-mode as well.  I think it's just a question of
> whether the first scroll reaches high enough line numbers to trigger a
> margin width adjustment.

Not sure what you mean by that.  In my experiments, the margin starts
at 3 columns, and stays at 3 columns.  There's no adjustment.

> > You can also trigger a slightly different messup by "M-<" after the
> > first scroll (which by itself looks OK).
> 
> Yes, in this case the top half of the other window gets lost.

Because Emacs scrolls the frame in the other direction.

bug#25666: Screen rendering bug

[npostavs]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: npostavs@users.sourceforge.net
>> Cc: 25666@debbugs.gnu.org,  fredde1994@gmail.com
>> Date: Sun, 12 Feb 2017 12:15:06 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I see the same here.  The frame dimensions are not relevant, btw: I
>> > can see this with any dimensions I tried.
>> 
>> Hmm, like the OP, I can't reproduce with an 80x24 terminal.
>
> I believe you because I didn't try with those dimensions ;-)
> The OP started by saying that the frame should be _wider_ than 80
> columns, and my assertion above should have been "the frame width is
> not relevant".

Hmm, I assumed height was relevant and missed the part about width.  But
trying now, I find that I can reproduce the bug with sizes 80x27 and
taller, and also 93x24 and wider.

>> >> It doesn't happen with nlinum-mode, probably because with nlinum-mode
>> >> when the left window scrolls, the margin in the right window is widened
>> >> too.
>> >
>> > I see this with nlinum-mode as well.  My terminal is PuTTY (which
>> > emulates xterm).
>> 
>> Ah, this depends on how high the terminal is.  With an 80x32 terminal I
>> see it with nlinum-mode as well.  I think it's just a question of
>> whether the first scroll reaches high enough line numbers to trigger a
>> margin width adjustment.
>
> Not sure what you mean by that.  In my experiments, the margin starts
> at 3 columns, and stays at 3 columns.  There's no adjustment.

With nlinum-mode it starts at 2 columns for me.  With a terminal 80x49
or higher, it widens before the bug happens.


[-- Attachment #2: initial state --]
[-- Type: image/png, Size: 32736 bytes --]

[-- Attachment #3: after 2nd scroll --]
[-- Type: image/png, Size: 35518 bytes --]

bug#25666: Screen rendering bug

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 25666@debbugs.gnu.org,  fredde1994@gmail.com
> Date: Sun, 12 Feb 2017 13:59:41 -0500
> 
> >> > I see this with nlinum-mode as well.  My terminal is PuTTY (which
> >> > emulates xterm).
> >> 
> >> Ah, this depends on how high the terminal is.  With an 80x32 terminal I
> >> see it with nlinum-mode as well.  I think it's just a question of
> >> whether the first scroll reaches high enough line numbers to trigger a
> >> margin width adjustment.
> >
> > Not sure what you mean by that.  In my experiments, the margin starts
> > at 3 columns, and stays at 3 columns.  There's no adjustment.
> 
> With nlinum-mode it starts at 2 columns for me.  With a terminal 80x49
> or higher, it widens before the bug happens.

Most of my experiments were with 80x38 terminal, where the margin
never widens during the first 2 scrolls.  And I see the problem with
nlinum-mode with that configuration.

I don't think margin widening has anything to do with the problem.
It's enough to have a post-command-hook that changes overlays, I
think.  But that's a guess, although it's based on the fact that the
problematic window doesn't need to be redrawn at all and doesn't need
any margin width adjustment.  The selected window, which is where the
margin width might change, is updated correctly.

bug#25666: split-screen + linum-mode in tall TTY fails to fully render other window after scrolling

[Lars Ingebrigtsen]

Fredrik Ljungdahl <fredde1994@gmail.com> writes:

> What I did to reproduce this bug under default settings:
> * I used a 146x46 size terminal (potentially matters)
> * Acquire this: http://sprunge.us/hVNi
> * Invoke emacs with emacs -Q
> * Go to this file (C-x C-f hVNi)
> * Invoke line number mode (M-x linum-mode), lack of linum-mode doesn't seem to
> reproduce this
> * Split the window (C-x 3)
> * Hold down C-n (C-v does not reproduce this)
> * On the 2nd half-scroll, the 2nd split window should have its rendering messed up
> in obvious ways

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried reproducing this in Emacs 29, but couldn't see anything odd
(running on Debian/bullseye with Gnome Terminal).  But skimming this
thread, it seems like it may be dependent on specific terminal sizes?

Do you still see this issue in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#25666: split-screen + linum-mode in tall TTY fails to fully render other window after scrolling

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I tried reproducing this in Emacs 29, but couldn't see anything odd
> (running on Debian/bullseye with Gnome Terminal).  But skimming this
> thread, it seems like it may be dependent on specific terminal sizes?
>
> Do you still see this issue in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no