From: Eli Zaretskii <eliz@gnu.org>
To: "Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>
Cc: 18912@debbugs.gnu.org
Subject: bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display
Date: Tue, 04 Nov 2014 18:16:49 +0200 [thread overview]
Message-ID: <83r3xjuej2.fsf@gnu.org> (raw)
In-Reply-To: <5458A9A2.3070108@gnu.org>
> Date: Tue, 04 Nov 2014 08:25:38 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
>
> > 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.
What do you mean by "scrolling", exactly? Which Emacs commands?
In any case, the initial display of "C-x d" doesn't involve any
scrolling, so it's not a "scrolling problem".
> 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.
What about moving cursor so it exits the visible portion of the
window, which also induces scrolling? And what about using the scroll
bar? Or just "M-x goto-char RET"? Are you saying these don't produce
a corrupted mode line?
> > 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
When you move to a different line, Emacs only redraws the line number
part of the mode line. Does that at least remove the corruption in
that area, or doesn't it?
In general, Emacs always redraws only the parts of the screen that
were changed. If you tell it to redraw, and nothing changed, it will
normally not redraw anything at all.
> because, by observation, updating the line number doesn't trigger
> the same kind of redraw that the 'xrefresh' command does.
Of course, it doesn't! Emacs doesn't use the technique used by
xrefresh, because Emacs tries to redraw as little as possible, not as
much as possible! xrefresh was coded specifically to force portions
of the screen to be completely redrawn, which is almost the
anti-thesis of the Emacs display engine.
Is there _any_ Emacs action that succeeds in redrawing the mode line
or its parts in a way that eliminates the corruption? I already asked
above about whether moving to a different line does that in the
portion that displays the line number. How about hovering the mouse
pointer over mouse-sensitive portions of the mode line, like the
buffer name and the major/minor mode indications? do they successfully
redraw the corresponding parts of the mode line?
What about "M-x redraw-display RET" -- does it fix the display of the
mode line?
If none of these helps, then I don't think Emacs can do anything at
all to help you work around the problem.
(And btw, why disabling the acceleration permanently isn't _the_
solution?)
> > 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)
Any change in window height that causes it to be an exact integral
multiple of the font height will eliminate the problem. The problem
is evidently caused by incorrect clipping of partially-visible lines.
That's why you see what you see.
next prev parent reply other threads:[~2014-11-04 16:16 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 13:46 bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display Bruno Félix Rezende Ribeiro
2014-10-31 20:30 ` Stefan Monnier
2014-10-31 20:44 ` Bruno Félix Rezende Ribeiro
2014-11-01 8:42 ` Eli Zaretskii
2014-11-01 12:56 ` Bruno Félix Rezende Ribeiro
2014-11-01 8:38 ` Eli Zaretskii
2014-11-01 9:16 ` Eli Zaretskii
2014-11-01 12:54 ` Bruno Félix Rezende Ribeiro
2014-11-01 13:03 ` Eli Zaretskii
2014-11-02 21:49 ` Bruno Félix Rezende Ribeiro
2014-11-03 3:34 ` Eli Zaretskii
2014-11-03 6:03 ` Bruno Félix Rezende Ribeiro
2014-11-03 16:20 ` Eli Zaretskii
2014-11-03 17:43 ` martin rudalics
2014-11-03 17:52 ` Eli Zaretskii
2014-11-03 18:01 ` martin rudalics
2014-11-03 18:19 ` Eli Zaretskii
2014-11-03 20:06 ` Bruno Félix Rezende Ribeiro
2014-11-03 20:24 ` Eli Zaretskii
2014-11-03 20:29 ` Eli Zaretskii
2014-11-03 20:46 ` Eli Zaretskii
2014-11-03 21:01 ` Bruno Félix Rezende Ribeiro
2014-11-03 21:19 ` Eli Zaretskii
2014-11-04 6:05 ` Bruno Félix Rezende Ribeiro
2014-11-04 8:25 ` Bruno Félix Rezende Ribeiro
2014-11-04 16:00 ` Eli Zaretskii
2014-11-04 19:24 ` martin rudalics
2014-11-04 19:52 ` Eli Zaretskii
2014-11-04 20:13 ` Stefan Monnier
2014-11-05 3:39 ` Eli Zaretskii
2014-11-05 9:17 ` Andreas Schwab
2014-11-04 21:09 ` Bruno Félix Rezende Ribeiro
2014-11-05 16:02 ` Eli Zaretskii
2014-11-05 21:38 ` Bruno Félix Rezende Ribeiro
2014-11-06 3:45 ` Eli Zaretskii
2014-11-06 15:28 ` Stefan Monnier
2014-11-04 15:54 ` Stefan Monnier
2014-11-04 21:28 ` Bruno Félix Rezende Ribeiro
2014-11-04 23:11 ` Stefan Monnier
2014-11-04 15:56 ` Eli Zaretskii
2014-11-04 19:24 ` martin rudalics
2014-11-04 20:55 ` Bruno Félix Rezende Ribeiro
2014-11-04 20:14 ` Bruno Félix Rezende Ribeiro
2014-11-05 3:51 ` Eli Zaretskii
2014-11-05 6:28 ` Bruno Félix Rezende Ribeiro
2014-11-05 15:58 ` Eli Zaretskii
2014-11-05 19:46 ` Bruno Félix Rezende Ribeiro
2014-11-03 20:55 ` Bruno Félix Rezende Ribeiro
2014-11-03 20:44 ` Bruno Félix Rezende Ribeiro
2014-11-03 9:08 ` Andreas Schwab
2014-11-03 16:23 ` Eli Zaretskii
2014-11-03 9:41 ` martin rudalics
2014-11-03 18:58 ` Bruno Félix Rezende Ribeiro
2014-11-03 19:14 ` Eli Zaretskii
2014-11-03 20:10 ` Bruno Félix Rezende Ribeiro
2014-11-04 7:55 ` martin rudalics
2014-11-04 8:20 ` Bruno Félix Rezende Ribeiro
2014-11-04 9:19 ` martin rudalics
2014-11-04 10:25 ` Bruno Félix Rezende Ribeiro
2014-11-04 16:16 ` Eli Zaretskii [this message]
2014-11-04 19:56 ` Bruno Félix Rezende Ribeiro
2014-11-04 19:23 ` martin rudalics
2014-11-04 21:46 ` Bruno Félix Rezende Ribeiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83r3xjuej2.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=18912@debbugs.gnu.org \
--cc=oitofelix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).