From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruno =?UTF-8?Q?F=C3=A9lix?= Rezende Ribeiro Newsgroups: gmane.emacs.bugs Subject: bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display Date: Tue, 04 Nov 2014 17:56:42 -0200 Organization: GNU Project Message-ID: <54592F7A.6010909@gnu.org> References: <54524135.8090405@gnu.org> <8361ezz56z.fsf@gnu.org> <5454D7EB.6060407@gnu.org> <83sii3xecv.fsf@gnu.org> <54574DDC.9020608@gmx.at> <5457D052.4090807@gnu.org> <54588656.3090207@gmx.at> <54588C52.7040804@gnu.org> <54589A1E.8040600@gmx.at> <5458A9A2.3070108@gnu.org> <83r3xjuej2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rXlfVKDWFfEdjru0hhGmB7RtfKRfXiaLB" X-Trace: ger.gmane.org 1415131095 25064 80.91.229.3 (4 Nov 2014 19:58:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 19:58:15 +0000 (UTC) Cc: 18912@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 04 20:58:08 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 1XlkEy-0006De-2e for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 20:58:08 +0100 Original-Received: from localhost ([::1]:42763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlkEx-0004uV-Pm for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 14:58:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlkEt-0004tc-Lq for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlkEs-00071K-7W for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:58:03 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlkEs-00071E-3b for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XlkEr-0003TY-Tt for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bruno =?UTF-8?Q?F=C3=A9lix?= Rezende Ribeiro Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Nov 2014 19:58: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.141513103013296 (code B ref 18912); Tue, 04 Nov 2014 19:58:01 +0000 Original-Received: (at 18912) by debbugs.gnu.org; 4 Nov 2014 19:57:10 +0000 Original-Received: from localhost ([127.0.0.1]:49196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlkE1-0003SN-Fc for submit@debbugs.gnu.org; Tue, 04 Nov 2014 14:57:10 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:38166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlkE0-0003SF-2K for 18912@debbugs.gnu.org; Tue, 04 Nov 2014 14:57:08 -0500 Original-Received: from 189-015-183-238.xd-dynamic.ctbcnetsuper.com.br ([189.15.183.238]:32789 helo=[192.168.1.17]) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1XlkDx-0002t6-Rw; Tue, 04 Nov 2014 14:57:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 In-Reply-To: <83r3xjuej2.fsf@gnu.org> 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:95503 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rXlfVKDWFfEdjru0hhGmB7RtfKRfXiaLB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii wrote: > What do you mean by "scrolling", exactly? Which Emacs commands? I mean by scroll the change of correspondence between window lines and buffer lines. It's not absolutely associated with any particular Emacs command. There are commands that are intended to directly cause scrolling, but don't do so in particular cases (eg. 'C-v' at the end of the buffer), and there are commands that are not directly intended to cause scrolling but do so in particular cases (eg. 'C-n' at the last visible line of a window). > In any case, the initial display of "C-x d" doesn't involve any=20 > scrolling, so it's not a "scrolling problem". You are right. That's a particular case for which the rule of thumb is: for newly created windows the mode-line should be drawn after the buffer's content is drawn. I think that would solve the problem. =46rom there forth, after any scrolling the mode-line should be (optionally) drawn after the buffer's content is drawn. > What about moving cursor so it exits the visible portion of the=20 > window, which also induces scrolling? It corrupts the mode-line as do 'C-l' typed multiple times. > And what about using the scroll bar? This too. > Or just "M-x goto-char RET"? Idem, as long as it causes scrolling and the new view has a buffer line "under" the mode-line. The same happens with the 'goto-line' command. > Are you saying these don't produce a corrupted mode line? Nope, actually all of them are capable of corrupting the mode-line. > 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? It does in that very area. > In general, Emacs always redraws only the parts of the screen that=20 > were changed. If you tell it to redraw, and nothing changed, it will > normally not redraw anything at all. It would be wise to provide a way to force Emacs to redraw, because there are factors beyond Emacs control and knowledge that could change the aspect of the frame. This bug is an example of that. > Of course, it doesn't! Emacs doesn't use the technique used by=20 > 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=20 > anti-thesis of the Emacs display engine. Again, sometimes it's necessary to redraw more than Emacs think it should. I'm not advocating to make Emacs redraw the whole frame, rather just the mode-line after very specific events. > Is there _any_ Emacs action that succeeds in redrawing the mode line > or its parts in a way that eliminates the corruption? Yes, there is. > I already asked above about whether moving to a different line does=20 > that in the portion that displays the line number. How about=20 > hovering the mouse pointer over mouse-sensitive portions of the mode > line, like the buffer name and the major/minor mode indications? This also eliminates the corruption. > do they successfully redraw the corresponding parts of the mode=20 > line? Yep. > What about "M-x redraw-display RET" -- does it fix the display of the > mode line? Nope, because it draws the buffer's content after redrawing the mode-line, overriding the mode-line refresh, in effect. > If none of these helps, then I don't think Emacs can do anything at=20 > all to help you work around the problem. They in fact help! So I think Emacs can do something to help me work around the problem, if you help Emacs to help me. ;-) > (And btw, why disabling the acceleration permanently isn't _the_=20 > solution?) Because the acceleration is not intended to cause that sort of problem. That's bug. Moreover, if I disable acceleration I would affect a lot more than just Emacs. On the other hand, the Emacs workaround I propose won't affect any other application or user of Emacs, and will help everyone else experiencing similar problems. =46rom my perspective, it's an improvement to make Emacs aware that it cannot know everything, and therefore we reserve the right to force it to redraw some parts of its frames, even if it doesn't feel like it, when we, the users, judge necessary. In particular Emacs must know that when redrawing the frame's content, it should first draw the buffer's content and only then the mode-line. > Any change in window height that causes it to be an exact integral=20 > multiple of the font height will eliminate the problem. The problem > is evidently caused by incorrect clipping of partially-visible=20 > lines. That's why you see what you see. That makes a lot of sense. --=20 ,=3D ,-_-. =3D. Bruno F=C3=A9lix Rezende Ribeiro (oitofelix) [0x28D618A= F] ((_/)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; --rXlfVKDWFfEdjru0hhGmB7RtfKRfXiaLB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUWS96AAoJECe5xv0o1hivQWwIAJGiWLN3q6rblcyEL+1Q6iBj jiCTM7OJYe/VAIY+JDkANy5F0JymvEDFGf3DcNZ4R29MMdJG/wAZqUFN8ZIBJILD gcJpasQnoR33ETW/yS3+JjuiNAseOrs3vmpHGzwjnbFgkjR+LrlSKSmAXAOsYTVT rKL+QwB8Ixq2FiSi1XFYlA8F1cvzvgYxrMfjeuQOk3oWnYV0WHaSJo60zlckVZ0w 43RFld02tloD7fmrUInu9gOISA7hbVxiHGul+uG+20AQgW3+iGQeQ7RbzES/KJK4 WxoZS8Xs94c6Wr5MZiXGhgvV045Ty+xneZY4zzihDoDGLkCHTEX2VoMTy04k9+Y= =rsS9 -----END PGP SIGNATURE----- --rXlfVKDWFfEdjru0hhGmB7RtfKRfXiaLB--