From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display Date: Wed, 05 Nov 2014 18:02:18 +0200 Message-ID: <838ujpvdo5.fsf@gnu.org> References: <54524135.8090405@gnu.org> <8361ezz56z.fsf@gnu.org> <5454D7EB.6060407@gnu.org> <83sii3xecv.fsf@gnu.org> <5456A6FE.90108@gnu.org> <83tx2hvtwp.fsf@gnu.org> <54571ABB.7020000@gnu.org> <83ppd4w910.fsf@gnu.org> <5457E044.9080300@gnu.org> <83bnoovxpi.fsf@gnu.org> <83a948vxh6.fsf@gnu.org> <837fzcvwph.fsf@gnu.org> <5457ED37.5080807@gnu.org> <8338a0vv6w.fsf@gnu.org> <54586C9D.2000801@gnu.org> <54588D65.8060506@gnu.org> <83sihzufav.fsf@gnu.org> <54594073.9070200@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1415203404 25978 80.91.229.3 (5 Nov 2014 16:03:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Nov 2014 16:03:24 +0000 (UTC) Cc: 18912@debbugs.gnu.org To: Bruno =?UTF-8?Q?F=C3=A9lix?= Rezende Ribeiro Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 05 17:03:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xm33F-0005wi-23 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Nov 2014 17:03:17 +0100 Original-Received: from localhost ([::1]:47195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm33E-0004kQ-Nj for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Nov 2014 11:03:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm336-0004jN-86 for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2014 11:03:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xm330-0006xs-Ae for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2014 11:03:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm330-0006xo-8G for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2014 11:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xm330-0001z7-0I for bug-gnu-emacs@gnu.org; Wed, 05 Nov 2014 11:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Nov 2014 16:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18912-submit@debbugs.gnu.org id=B18912.14152033467588 (code B ref 18912); Wed, 05 Nov 2014 16:03:01 +0000 Original-Received: (at 18912) by debbugs.gnu.org; 5 Nov 2014 16:02:26 +0000 Original-Received: from localhost ([127.0.0.1]:50162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xm32P-0001yJ-Os for submit@debbugs.gnu.org; Wed, 05 Nov 2014 11:02:26 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44343) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xm32N-0001y7-3f for 18912@debbugs.gnu.org; Wed, 05 Nov 2014 11:02:23 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEK00900PTYSD00@a-mtaout22.012.net.il> for 18912@debbugs.gnu.org; Wed, 05 Nov 2014 18:02:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEK0099VPVXE970@a-mtaout22.012.net.il>; Wed, 05 Nov 2014 18:02:22 +0200 (IST) In-reply-to: <54594073.9070200@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95539 > Date: Tue, 04 Nov 2014 19:09:07 -0200 > From: Bruno Félix Rezende Ribeiro > 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.