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

[Bruno Félix Rezende Ribeiro]

martin rudalics wrote:

> I don't understand what "moving the frame" means.  Does "left side" 
> mean VGA1 and "right side" LVDS1?

No.  When the frame is shown it has its left border touching the left
extremity of the VGA1 output, so by "moving the frame to the right
side" I meant moving the frame horizontally to the right until its
right border touches the right extremity of the VGA1 output.

> What evidence do you have that the window manager "resizes" the frame
> when you move it?

'xwininfo' tool reports the frame had 697 pixels of height before the
move, but 696 afterwards.

> And you get the corrupted mode line when you do "not move" the frame
> as well?

Yes, I do.  However, the frame 696 pixels tall doesn't corrupt the
mode-line, as shown by previous experiments.  A full-screen frame
corrupts it, though.

> Elsewhere you asked to "please, provide a way to make Emacs 
> optionally redraw the mode-line after any scroll operation".  How 
> does scrolling enter here?

After getting the mode-line right by refreshing the frame, only
scrolling can possibly corrupt the mode-line again.

> Do you have to scroll the window in order to show the corruption?

If the frame was refreshed, yes.

> Maybe you could give us a step-by-step scenario of what you do to the
> show the corruption, how to remove it afterwards, and how to show it
> again after it was temporarily removed.

After creating the frame with 'emacs -Q', typing 'C-x d /dev RET'
takes me to a Dired buffer with a corrupted mode-line as shown in the
picture attached to the original bug report.  There, typing 'M-!
xrefresh RET' repaints the whole frame and the mode-line is shown
normally as one would expect.  Scrolling the text up with 'C-v'
corrupts the mode-line again.

> I don't have the slightest idea why the mode line would _not_ be
> redrawn after scrolling but maybe there's some optimization here.  In
> any case with emacs -Q moving the window's point from one line to
> another should redraw the mode line to show the new line number.

If it redraws the mode-line, it does so while corrupting the mode-line
again, because, by observation, updating the line number doesn't
trigger the same kind of redraw that the 'xrefresh' command does.

> BTW, suppose you evaluate
> 
> (set-frame-parameter nil 'bottom-divider-width 8)
> 
> Does that impact the appearance of the bug in any way?

Yes, it does.  The mode-line still gets corrupt but this time by the
lower half (approximately) of the line above the one that corrupted it
originally.

Interesting enough,

(set-frame-parameter nil 'bottom-divider-width 1)

fixes the problem for the original frame.  Unfortunately when
in full-screen the mode-line is corrupted again; what is fixed in the
VGA1 output by

(set-frame-parameter nil 'bottom-divider-width 7)

and in the LVDS1 output by

(set-frame-parameter nil 'bottom-divider-width 12)

I'd miss some useful screen area, though.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;

signature.asc
Description: OpenPGP digital signature