Redisplay bug

Redisplay bug

[Andreas Schwab]

Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs
manual, scroll down 2 pages.  When I now scroll back 2 pages the display
is completely messed up.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Redisplay bug

[D. Goel]

Andreas Schwab <schwab@suse.de> writes:

> Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs


yes, i see the bug:
(cvs)
emacs -q -no-site-file
C-h i
tab, tab to get to emacs, RET
C-v C-v
M-v M-v

Re: Redisplay bug

[Luc Teirlinck]

Andreas Schwab wrote:

   Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs
   manual, scroll down 2 pages.  When I now scroll back 2 pages the display
   is completely messed up.

This seems related to the header line.

After: 

(setq Info-use-header-line nil)

the problem disappears.

Sincerely,

Luc.

Re: Redisplay bug

[Andreas Schwab]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

|> Andreas Schwab wrote:
|> 
|>    Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs
|>    manual, scroll down 2 pages.  When I now scroll back 2 pages the display
|>    is completely messed up.
|> 
|> This seems related to the header line.

I don't think so.  Another way to trigger the bug: enable
global-font-lock-mode, load some C file, resize Emacs so that the last
line is only partially visible, ie. the frame size is not a multiple of
the font size.  Now type M-> to go to point-max and scroll up one line at
a time (M-1 M-v).  As soon as the cursor hits the last frame line the
display is garbled.  This happens only when point is at point-max.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Redisplay bug

[Andreas Schwab]

|> I don't think so.  Another way to trigger the bug: enable
|> global-font-lock-mode, load some C file, resize Emacs so that the last

Actually, enabling global-font-lock-mode is not necessary.

|> line is only partially visible, ie. the frame size is not a multiple of
|> the font size.  Now type M-> to go to point-max and scroll up one line at
|> a time (M-1 M-v).  As soon as the cursor hits the last frame line the
|> display is garbled.  This happens only when point is at point-max.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Redisplay bug

[Simon Josefsson]

Andreas Schwab <schwab@suse.de> writes:

> Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs
> manual, scroll down 2 pages.  When I now scroll back 2 pages the display
> is completely messed up.

Yup.  Reported it a few days ago, but it wasn't possible to reproduce
it.  What is the common denominator here?  I'm using Debian sid and
rebuilt Emacs freshly with make distclean + ./configure + make
bootstrap.

This thread mentioned font-lock too and I'm seeing weird font-lock
behaviour in C-mode too.  Unless it is fixed by fixing the above
problem (which I suspect), I can do a proper bug report.

> With current CVS:
> 
> emacs -q --no-site-file
> C-h i m gnus RET s button-url PGDN PGUP PGUP
> 
> After this the emacs buffer is garbled but C-l helps.

Re: Redisplay bug

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> 
> |> Andreas Schwab wrote:
> |> 
> |>    Does anyone else see this redisplay bug?  I do M-x info, visit the Emacs
> |>    manual, scroll down 2 pages.  When I now scroll back 2 pages the display
> |>    is completely messed up.
> |> 
> |> This seems related to the header line.
> 
> I don't think so.  Another way to trigger the bug: enable
> global-font-lock-mode, load some C file, resize Emacs so that the last
> line is only partially visible, ie. the frame size is not a multiple of
> the font size.  Now type M-> to go to point-max and scroll up one line at
> a time (M-1 M-v).  As soon as the cursor hits the last frame line the
> display is garbled.  This happens only when point is at point-max.
> 

This has been reported several times now.

It is related to changes Richard made to xdisp.c some time ago.

The change was intended to fix a problem with scrolling leaving a
partially visible line at the bottom (or top) of the window -- but the
change doesn't work correctly when that line is the last (first) line
of the buffer.

Is someone working on fixing this, or should I give it a try?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Redisplay bug

[Richard Stallman]

I keep meaning to work on debugging this, but keep being too busy.
I would be really grateful if you would try it.  It surely relates
to one of the places I changed a call to make_cursor_line_fully_visible.
The first question is, which one?

Re: Redisplay bug

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I keep meaning to work on debugging this, but keep being too busy.
> I would be really grateful if you would try it.  It surely relates
> to one of the places I changed a call to make_cursor_line_fully_visible.
> The first question is, which one?

Ok, I'll look into this over the next week or so.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Redisplay bug

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > I keep meaning to work on debugging this, but keep being too busy.
> > I would be really grateful if you would try it.  It surely relates
> > to one of the places I changed a call to make_cursor_line_fully_visible.
> > The first question is, which one?
> 
> Ok, I'll look into this over the next week or so.
> 


I've spent quite some time trying to track this bugger down....

I found a specific part of Richard's change to xdisp.c which seems
to cause the redisplay problem, so I have reverted that change.

But now the redisplay again has a habit of leaving the cursor on
partially visible lines at the top or bottom of the window (which
I believe is what Richard tried to fix).  

IMO, a partially visible line is preferable to a messed up display,
but someone should work on finding the proper fix for this.  

See my comments in the xdisp.c source if you like to do that...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Redisplay bug

[Lute Kamstra]

storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> > > I keep meaning to work on debugging this, but keep being too busy.
> > > I would be really grateful if you would try it.  It surely relates
> > > to one of the places I changed a call to make_cursor_line_fully_visible.
> > > The first question is, which one?
> > 
> > Ok, I'll look into this over the next week or so.
> 
> I've spent quite some time trying to track this bugger down....
> 
> I found a specific part of Richard's change to xdisp.c which seems
> to cause the redisplay problem, so I have reverted that change.
> 
> But now the redisplay again has a habit of leaving the cursor on
> partially visible lines at the top or bottom of the window (which
> I believe is what Richard tried to fix).  

There seems to be some confusion as to what Richard was trying to
implement with his change to xdisp.c which is causing the redisplay
bug.  It is my understanding that he was trying to implement the
following.

  http://mail.gnu.org/pipermail/emacs-devel/2002-June/009864.html

Richard, if I'm mistaken, please correct me.  Sorry for the noise in
that case.

Regards,

  Lute.

-- 
Lute Kamstra  <Lute.Kamstra@cwi.nl>
CWI  department PNA4
Room M233  phone (+31) 20 592 4214
[Echelon material: codes benelux Defcon]

Re: Redisplay bug

[Kim F. Storm]

Lute Kamstra <Lute.Kamstra@cwi.nl> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > But now the redisplay again has a habit of leaving the cursor on
> > partially visible lines at the top or bottom of the window (which
> > I believe is what Richard tried to fix).  
> 
> There seems to be some confusion as to what Richard was trying to
> implement with his change to xdisp.c which is causing the redisplay
> bug.  It is my understanding that he was trying to implement the
> following.
> 
>   http://mail.gnu.org/pipermail/emacs-devel/2002-June/009864.html
> 
> Richard, if I'm mistaken, please correct me.  Sorry for the noise in
> that case.

Thanks for the noise Lute :-)  

My new fix does not change the new behavoiur described there, so maybe
it actually the right fix :-)

But I still think it is pretty irritating that the new behaviour implies
that when I scroll up (page down), the last line in the window may
be partially visible even when the cursor is over it...

++kfs

Re: Redisplay bug

[Richard Stallman]

    I found a specific part of Richard's change to xdisp.c which seems
    to cause the redisplay problem, so I have reverted that change.

    But now the redisplay again has a habit of leaving the cursor on
    partially visible lines at the top or bottom of the window (which
    I believe is what Richard tried to fix).  

Of course.  Reverting that part of the change shows you found the
right place, but it is not the right fix.

Can you show me which change it was?

Re: Redisplay bug

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I found a specific part of Richard's change to xdisp.c which seems
>     to cause the redisplay problem, so I have reverted that change.
> 
>     But now the redisplay again has a habit of leaving the cursor on
>     partially visible lines at the top or bottom of the window (which
>     I believe is what Richard tried to fix).  
> 
> Of course.  Reverting that part of the change shows you found the
> right place, but it is not the right fix.
> 
> Can you show me which change it was?

Here is the change I made.  Only one line of code with a large comment
on why I changed this.  Hope it is enough for you to work on.

Index: xdisp.c
===================================================================
RCS file: /cvs/emacs/src/xdisp.c,v
retrieving revision 1.776
retrieving revision 1.777
diff -c -r1.776 -r1.777
*** xdisp.c	9 Aug 2002 17:29:11 -0000	1.776
--- xdisp.c	22 Aug 2002 16:52:56 -0000	1.777
***************
*** 10365,10371 ****
  	}
  
        if (!make_cursor_line_fully_visible (w))
! 	goto try_to_scroll;
  #if GLYPH_DEBUG
        debug_method_add (w, "forced window start");
  #endif
--- 10365,10408 ----
  	}
  
        if (!make_cursor_line_fully_visible (w))
! 	{
! 	  /* CVS rev. 1.761 had changed this to ``goto try_to_scroll''.
! 
! 	     The intention of the fix -- AFAIU -- was to ensure that 
! 	     the cursor didn't end up on a partially visible last (or
! 	     first?) line when scrolling.
! 
! 
! 	     But that change causes havoc when scrolling backwards and
! 	     a partially visible first (or last?) line is present when
! 	     we reach the top of the buffer.  In effect, the text
! 	     already in the window is repeated (each line is appended
! 	     to the same or another lines in the window)...
! 
! 	     I changed it back to ``goto need_larger_matrices'' which
! 	     in effect mean that we don't go through `try_scrolling'
! 	     when the cursor is already at the first line of the buffer,
! 	     and there is really only a few pixels [rather than lines]
! 	     to scroll backwards.  I guess move_it_by_lines etc. really
! 	     isn't the right device for doing that, ref. the code in
! 	     make_cursor_line_fully_visible which was also disabled by
! 	     CVS rev. 1.761.
! 
! 	     But how do we know that we are already on the top line of
! 	     the window showing the first line in the buffer, so that
! 	     scrolling really wont help here?
! 
! 	     I cannot find a simple fix for this (I tried various
! 	     approaches), but I prefer to an occasional partial line
! 	     rather than the visual messup, so I reverted this part of
! 	     the fix.
! 
! 	     Someone will need to look into this when time allows.
! 
! 	     -- 2002-08-22, Kim F. Storm  */
! 
! 	  goto need_larger_matrices;
! 	}
  #if GLYPH_DEBUG
        debug_method_add (w, "forced window start");
  #endif

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Redisplay bug

[Eli Zaretskii]

On 26 Aug 2002, Kim F. Storm wrote:

> >     But now the redisplay again has a habit of leaving the cursor on
> >     partially visible lines at the top or bottom of the window (which
> >     I believe is what Richard tried to fix).  
> > 
> > Of course.  Reverting that part of the change shows you found the
> > right place, but it is not the right fix.
> > 
> > Can you show me which change it was?
> 
> Here is the change I made.  Only one line of code with a large comment
> on why I changed this.  Hope it is enough for you to work on.

I think when point enters a partially visible line, redisplay should 
behave as if that line were invisible, i.e. scroll the display (by 
default, by half the window height) to bring the point's line into the 
visible area.  If such a change in behavior is not something that 
requires to rewrite large parts of the display code, I'd suggest to make 
it so.

Re: Redisplay bug

[Richard Stallman]

    I think when point enters a partially visible line, redisplay should 
    behave as if that line were invisible, i.e. scroll the display (by 
    default, by half the window height) to bring the point's line into the 
    visible area.

Yes, that is what I was trying to do.

Re: Redisplay bug

[Richard Stallman]

I figured out the problem, and I think I have fixed it properly now.
Thanks.

Re: Redisplay bug

[Juanma Barranquero]

On Sat, 31 Aug 2002 12:58:22 -0400, Richard Stallman <rms@gnu.org> wrote:

> I figured out the problem, and I think I have fixed it properly now.
> Thanks.

If you're referring to the problem with garbled redisplay with partially
visible lines, it's still there (at least on W2K).


                                                           /L/e/k/t/u

Re: Redisplay bug

[Miles Bader]

Juanma Barranquero <lektu@terra.es> writes:
> If you're referring to the problem with garbled redisplay with partially
> visible lines, it's still there (at least on W2K).

Yeah, I saw it today too (in a fresh-from-CVS emacs), but it was
fleeting, and I can't seem reproduce on demand (the first time it
happened when Gnus updated its *Group* buffer after a long delay reading
in new mail etc).

It does seem to be fixed in the cases I could use to reproduce before
(scrolling line-by-line until the cursor hit the end of the window), so
it's possible that this is a different bug that looks the same.

[The distinctive feature that suggests that it may be the same bug is
that the garbage characters are actually the real screen horizontally
shifted over.]

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Redisplay bug

[Juanma Barranquero]

On 02 Sep 2002 15:40:33 +0900, Miles Bader <miles@lsi.nec.co.jp> wrote:

> Yeah, I saw it today too (in a fresh-from-CVS emacs), but it was
> fleeting, and I can't seem reproduce on demand. It does seem to be fixed
> in the cases I could use to reproduce before (scrolling line-by-line
> until the cursor hit the end of the window),

I can reproduce it easily on my W2K MSVC-compiled Emacs:

emacs -q --no-site-file
C-h N
M-: (setq scroll-conservatively 100000)
M-x ruler-mode
<down>...                  ; until the buffer is scrolled

> [The distinctive feature that suggests that it may be the same bug is
> that the garbage characters are actually the real screen horizontally
> shifted over.]

Yes. And I reproduce it exactly like I did before, so the chance of it
being another bug seems small.


                                                           /L/e/k/t/u