GNU bug report logs - #18912
24.4; mode-line corruption on graphical frames in dual-headed display

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
Cc: 18912 <at> debbugs.gnu.org
Subject: bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display
Date: Wed, 05 Nov 2014 18:02:18 +0200

> Date: Tue, 04 Nov 2014 19:09:07 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix <at> gnu.org>
> CC: 18912 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > You'd need to explain how Emacs succeeds in that, when it uses Xlib
> > and higher-level APIs, which AFAIK are unaware of any accelerations.
> > Emacs itself is certainly unaware of that, and does the same things
> > regardless.
> 
> The Emacs algorithms for redrawing the frame's content could be based on
> assumptions about the workings of graphical displays that fail to be
> true in some corner cases.

AFAIK, the only assumptions made by Emacs are that each screen line of
the display is independently addressable, which means the order of
drawing those lines doesn't matter; and that clipping of partially
visible text works.

> [xrefresh] works by mapping a window, with no background, on top of
> the Emacs' frames, and then unmapping it, causing the X server to
> send a refresh event to Emacs, that handles it and repaints its
> frames.

If we want to make sure Emacs indeed redraws its frame in your case
(rather than X reusing its own copy of the screen, as Andreas points
out), please put a breakpoint in expose_frame, and see if it breaks
when you invoke xrefresh.

> So Emacs *do know* how to get its frames right, when it wants to.

Does it?  We were talking all along about the simplest situation, when
the Emacs frame has only one window and thus a single mode line, and
the clipped text line is the last line of that window.  But this is by
no means so in general.  Here, try this:

  emacs -Q
  C-x d /dev RET
  C-x 2
  C-x o
  C-v

At this point, you should see the lower of the 2 windows selected,
with its contents scrolled, such that each of the 2 windows showing 2
different places in /dev's directory listing.

Now invoke xrefresh to clean up the mode lines and start with a "clean
slate".

Finally, type inside Emacs:

  M-: (set-window-vscroll nil 5 t) RET

How many mode lines did that corrupt?  If both mode lines become
corrupted, does xrefresh succeed in fixing that?

Bonus points for repeating the above after setting mode-line-format to
nil.  I expect you to see that the 2 windows corrupt each other in
that case.

Previous Next

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