Display bug using bold/italic faces & header line

Display bug using bold/italic faces & header line

[David Ponce]

Hi all,

In GNU Emacs 21.3.50.1 (i386-mingw-nt4.0.1381)
 of 2002-07-15 on EBAT311
configured using `configure --with-gcc (2.95)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

There is a nasty bug in the display engine of the latest CVS version
of Emacs 21 that displays garbaged text in buffers when scrolling up.

After some investigation I found that this occurred when both the
header line is displayed and the buffer contains text in bold or
italic faces.

A simple way to reproduce the bug is to start:

emacs -q--no-site-file

and display the Emacs manual in info.  Just scrolling the info buffer
page down twice or more, then page up twice or more shows the garbaged
display.  When I set `Info-use-header-line' to nil the bug
disappeared.

I also have this problem in other buffers when ruler-mode (which uses
the header line) is enabled because I use italic and bold font-lock
faces.

It seems that the following changes in xdisp.c caused the bug:

2002-07-07  Richard M. Stallman  <rms@gnu.org>

* xdisp.c (make_cursor_line_fully_visible): Don't try short scrolls.
Instead just return 0 when there is something to be done.
(try_scrolling): If make_cursor_line_fully_visible returns 0,
retry scrolling as if cursor were off the bottom.
(try_cursor_movement): If make_cursor_line_fully_visible returns 0,
return CURSOR_MOVEMENT_MUST_SCROLL.
(redisplay_window): If make_cursor_line_fully_visible returns 0,
go to try_to_scroll.

After reverting the above changes all worked well again.

I hope all that will help.

Sincerely,
David

[PATCH] Re: Display bug using bold/italic faces & header line

[Kim F. Storm]

David Ponce <david@dponce.com> writes:

> There is a nasty bug in the display engine of the latest CVS version
> of Emacs 21 that displays garbaged text in buffers when scrolling up.

I saw that too.

C-h i C-v C-v M-v M-v 

is enough to reproduce.

> 
> It seems that the following changes in xdisp.c caused the bug:
> 
> 2002-07-07  Richard M. Stallman  <rms@gnu.org>
> 
> * xdisp.c (make_cursor_line_fully_visible): Don't try short scrolls.
> Instead just return 0 when there is something to be done.
> (try_scrolling): If make_cursor_line_fully_visible returns 0,
> retry scrolling as if cursor were off the bottom.
> (try_cursor_movement): If make_cursor_line_fully_visible returns 0,
> return CURSOR_MOVEMENT_MUST_SCROLL.
> (redisplay_window): If make_cursor_line_fully_visible returns 0,
> go to try_to_scroll.
> 

Yes, the problems are definitely related to those changes.  I cannot
see from the changelog why these changes were needed, but I assume
they solved some problem...  Richard, do you recall which?

The following patch seems to fix the present problems by undoing two
of these changes.  However, without knowledge about what the original
change was supposed to fix, I don't know if my patch reintroduces that
problem.  Also, my patch may be incomplete in the sense that there are
still cases which display incorrectly...


Index: xdisp.c
===================================================================
RCS file: /cvs/emacs/src/xdisp.c,v
retrieving revision 1.765
diff -c -r1.765 xdisp.c
*** xdisp.c	15 Jul 2002 20:37:12 -0000	1.765
--- xdisp.c	15 Jul 2002 22:58:54 -0000
***************
*** 10056,10062 ****
  		  set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0);
  		  try_window (window, startp);
  		  if (!make_cursor_line_fully_visible (w))
! 		    rc = CURSOR_MOVEMENT_MUST_SCROLL;
  		  else
  		    rc = CURSOR_MOVEMENT_SUCCESS;
  		}
--- 10056,10062 ----
  		  set_cursor_from_row (w, row, w->current_matrix, 0, 0, 0, 0);
  		  try_window (window, startp);
  		  if (!make_cursor_line_fully_visible (w))
! 		    rc = CURSOR_MOVEMENT_NEED_LARGER_MATRICES;
  		  else
  		    rc = CURSOR_MOVEMENT_SUCCESS;
  		}
***************
*** 10347,10353 ****
  	}
  
        if (!make_cursor_line_fully_visible (w))
! 	goto try_to_scroll;
  #if GLYPH_DEBUG
        debug_method_add (w, "forced window start");
  #endif
--- 10347,10353 ----
  	}
  
        if (!make_cursor_line_fully_visible (w))
! 	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: [PATCH] Re: Display bug using bold/italic faces & header line

[Richard Stallman]

    Yes, the problems are definitely related to those changes.  I cannot
    see from the changelog why these changes were needed, but I assume
    they solved some problem...  Richard, do you recall which?

The purpose of this change is that moving point into a partially
visible line should scroll in the usual way.

I will debug it when I have a chance.  But if someone else can debug
it for me, I would appreciate that.

Re: [PATCH] Re: Display bug using bold/italic faces & header line

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Yes, the problems are definitely related to those changes.  I cannot
>     see from the changelog why these changes were needed, but I assume
>     they solved some problem...  Richard, do you recall which?
> 
> The purpose of this change is that moving point into a partially
> visible line should scroll in the usual way.
> 
> I will debug it when I have a chance.  But if someone else can debug
> it for me, I would appreciate that.

Maybe the problem is related to the cursor ending up in a partially
visible line _after_ scrolling, and then trying to scroll again...


One observation from C-h i C-v C-v M-v M-v is that it only happens
when scrolling backwards, and the problem happens when the first
"page" of the buffer is displayed.

In the C-h i case, it seems that the top-line (== first line in
buffer) is only partially visible ...

Maybe it really doesn't make sense to try to _scroll_ any further
backwards in this case, but rather the old "need_larger_matrices"
behaviour is really the proper thing to do.  At least that is what my
patch indicates (it replaces two of the attempts to scroll by the
"need larger matrices" functionality).  

Currently it does this unconditionally, but it might make sense to
distinguish whether:

- we have already scrolled some distance [this is speculation]

- we are scrolling backwards and it is the first line of the buffer
  which is partially visible, so don't try "real" scrolling here.

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