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

Previous Next

Full log

Message #42 received at 25666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: fredde1994 <at> gmail.com, 25666 <at> debbugs.gnu.org
Subject: Re: bug#25666: Screen rendering bug
Date: Sun, 12 Feb 2017 18:47:24 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  25666 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.