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#11068: 24.0.94; Face-remapped background does not extend to end of window Date: Sun, 25 Mar 2012 19:22:25 +0200 Message-ID: <83r4wgsii6.fsf@gnu.org> References: <1BE52A40-0403-433F-8164-DFDBD6771F80@gmail.com> <83ty1fvc28.fsf@gnu.org> <83obrmtbsy.fsf@gnu.org> <4F6DCF31.3060609@gmx.at> <83fwcyt7f0.fsf@gnu.org> <4F6E24FD.2070907@gmx.at> <83wr69sp4e.fsf@gnu.org> <4F6F1574.2090904@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1332696250 20894 80.91.229.3 (25 Mar 2012 17:24:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2012 17:24:10 +0000 (UTC) Cc: darthandrus@gmail.com, 11068@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 25 19:24:03 2012 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 1SBrAg-0003ZA-PD for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Mar 2012 19:24:03 +0200 Original-Received: from localhost ([::1]:48944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBrAf-0006zm-SC for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Mar 2012 13:24:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBrAd-0006zZ-8g for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 13:24:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBrAb-0004lA-84 for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 13:23:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBrAb-0004l3-4O for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 13:23:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SBref-00089V-MA for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 13:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Mar 2012 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11068 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11068-submit@debbugs.gnu.org id=B11068.133269806131288 (code B ref 11068); Sun, 25 Mar 2012 17:55:01 +0000 Original-Received: (at 11068) by debbugs.gnu.org; 25 Mar 2012 17:54:21 +0000 Original-Received: from localhost ([127.0.0.1]:38490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBre0-00088a-Nn for submit@debbugs.gnu.org; Sun, 25 Mar 2012 13:54:21 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61095) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBrdj-000886-Hx for 11068@debbugs.gnu.org; Sun, 25 Mar 2012 13:54:18 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1G00800AWSY500@a-mtaout22.012.net.il> for 11068@debbugs.gnu.org; Sun, 25 Mar 2012 19:22:25 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.240.24]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1G007ACAXB2IT0@a-mtaout22.012.net.il>; Sun, 25 Mar 2012 19:22:25 +0200 (IST) In-reply-to: <4F6F1574.2090904@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:58132 Archived-At: > Date: Sun, 25 Mar 2012 14:54:12 +0200 > From: martin rudalics > CC: darthandrus@gmail.com, monnier@iro.umontreal.ca, > cyd@stupidchicken.com, 11068@debbugs.gnu.org > > > What the changes I suggested do is add stretch glyphs of a suitably > > computed width to each glyph row that has no text in it. The changes > > are small because the code that does that was already written for the > > bidirectional display, which needs to display R2L lines flushed all > > the way to the right margin of the window; it does that by prepending > > such a stretch glyph to the R2L glyph rows, ahead (i.e to the left) of > > the text. All I needed was to activate that code for the case of > > remapped default face, in addition to R2L lines. > > Consider the following example: In my .emacs I do for ages > > (custom-set-faces > '(font-lock-comment-face ((((class color) (background light)) (:background "Beige" :foreground "Black"))))) > > Evaluate this form with emacs -Q in *scratch* and you will see that the > background color extends from each buffer line end to the right window > edge. Yes, that's true (and well known). > Anyway, my conclusion from this example is that even in normal L2R text > Emacs somehow constructs a stretch glyph (or whatever else) to simulate > the effect of text properties over some virtual text. Correct. But only for lines that end before EOB. The line that ends _at_ EOB and all the subsequent lines don't have this stretch glyph. The changes I did introduce such stretch glyphs for _all_ lines in the window than don't already have them. > I assume that your solution does something equivalent for every > virtual buffer line that is missing down to the bottom of the > window. Yes. > And it takes the face property not from the return character but > from the remapped default face. No, the return character has no face, and in fact it has no glyphs. The original code would reset the face to the (un-remapped) default face when it hits the line at EOB, and would not draw past EOB at all, instead relying on the display-specific code that clears the rest of the window with the default color. Since now there are stretch glyphs there, we do draw in those areas, and we draw in the precise face that remapping specifies. > Apart from that why do you need a solution from R2L lines here? Nothing, I just reused the machinery that was invented for R2L lines. > As an aside I earlier tried to achieve the effect of your patch by > adding an overlay with an after-string containing an appropriate number > of return characters to the last character of each buffer. It didn't > work and I still consider that a bug. If you show me the code, I will see if it's a bug or something else.