unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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: Wed, 05 Nov 2014 18:02:18 +0200	[thread overview]
Message-ID: <838ujpvdo5.fsf@gnu.org> (raw)
In-Reply-To: <54594073.9070200@gnu.org>

> Date: Tue, 04 Nov 2014 19:09:07 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@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.





  reply	other threads:[~2014-11-05 16:02 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 [this message]
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
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=838ujpvdo5.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).