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.