GNU bug report logs - #10304
24.0.92: display bug

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 10304 <at> debbugs.gnu.org, yagnesh <at> live.com
Subject: Re: bug#10304: 24.0.92: display but
Date: Sat, 07 Jan 2012 10:48:32 +0200

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: 10304 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 07 Jan 2012 02:20:50 +0100
> 
> Yagnesh Raghava Yakkala <yagnesh <at> live.com> writes:
> 
> > I see this thing occasionally when reading news in group. I cant
> > reproduce it at will.
> >
> > This screen shot is from article buffer, you can see the first line
> > starts with "I tend to ... " is displayed twice in the screen (bottom
> > also same line). In fact this messages was long, the line "I tend to
> > ..."  displayed at the bottom at the beginning. then I needed to hit SPC
> > to read remaining part of the message. So the last line stays there
> 
> Eli, if you look at the image included in this bug report, this looks
> like the same display bug that I've seen a few times.  It's as if Emacs
> isn't clearing some parts of the screen when scrolling.  (Sometimes.)
> 
> I still haven't been able to make a test case for this.  It happens to
> me like a couple of times a week, so it's pretty obscure...

Probably some redisplay optimization that doesn't exactly DTRT.

When this happens, does it help to type "M-x redraw-display RET"?  If
it does, then, in the absence of a reproducible test case, all I can
suggest is gather more info to narrow the range of possible
offenders.  Start by rebuilding Emacs with -DGLYPH_DEBUG=1, then start
Emacs with stderr redirected to a file, toggle redisplay tracing with
"M-x trace-redisplay RET", and wait till the problem happens.  When it
does, make the window with incorrect display the currently selected
window, and type "M-x dump-glyph-matrix RET".  Finally, send the
contents of the redirected stderr here.

There are also several variables that inhibit certain redisplay
optimizations.  They are defined in xdisp.c and are available only
when Emacs is compiled with -DGLYPH_DEBUG=1:

  #if GLYPH_DEBUG
    DEFVAR_BOOL ("inhibit-try-window-id", inhibit_try_window_id,
		 doc: /* Inhibit try_window_id display optimization.  */);
    inhibit_try_window_id = 0;

    DEFVAR_BOOL ("inhibit-try-window-reusing", inhibit_try_window_reusing,
		 doc: /* Inhibit try_window_reusing display optimization.  */);
    inhibit_try_window_reusing = 0;

    DEFVAR_BOOL ("inhibit-try-cursor-movement", inhibit_try_cursor_movement,
		 doc: /* Inhibit try_cursor_movement display optimization.  */);
    inhibit_try_cursor_movement = 0;
  #endif /* GLYPH_DEBUG */

By selectively turning off each of these optimizations, we could zero
in on the optimization that causes this bug.  However, using these
variables effectively needs some initial ideas about the possible
causes, so I think gathering the info as suggested above is best as
the first step.

Previous Next

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