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.