From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 14:54:12 +0200 Message-ID: <4F6F1574.2090904@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1332680108 5928 80.91.229.3 (25 Mar 2012 12:55:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2012 12:55:08 +0000 (UTC) Cc: darthandrus@gmail.com, 11068@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 25 14:55:05 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 1SBmyP-0005ES-Dz for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Mar 2012 14:55:05 +0200 Original-Received: from localhost ([::1]:35159 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmyO-00049i-Qr for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Mar 2012 08:55:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmyK-00044V-J4 for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 08:55:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBmyI-0005tN-PV for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 08:55:00 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmyI-0005tJ-M4 for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 08:54:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SBnSM-00005v-3H for bug-gnu-emacs@gnu.org; Sun, 25 Mar 2012 09:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Mar 2012 13:26: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.1332681937330 (code B ref 11068); Sun, 25 Mar 2012 13:26:01 +0000 Original-Received: (at 11068) by debbugs.gnu.org; 25 Mar 2012 13:25:37 +0000 Original-Received: from localhost ([127.0.0.1]:37658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBnRw-00005F-9p for submit@debbugs.gnu.org; Sun, 25 Mar 2012 09:25:37 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:51218) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SBnRd-0008WR-9i for 11068@debbugs.gnu.org; Sun, 25 Mar 2012 09:25:33 -0400 Original-Received: (qmail invoked by alias); 25 Mar 2012 12:54:12 -0000 Original-Received: from 62-47-44-190.adsl.highway.telekom.at (EHLO [62.47.44.190]) [62.47.44.190] by mail.gmx.net (mp039) with SMTP; 25 Mar 2012 14:54:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/z7dpo44Lz3bGKX5tcnP+GbCpMRj97jr90HJZ58m LYZQR/pI+T7g4H In-Reply-To: <83wr69sp4e.fsf@gnu.org> X-Y-GMX-Trusted: 0 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:58121 Archived-At: >> But the same holds for the current patch as well: You simply fill up >> the rest of the window with the background of the remapped default >> face. > > No, not only background. The entire face with all its attributes is > used. E.g., stipple (which doesn't work on MS-Windows), font > (i.e. the size of each line in pixels), etc. > > And you cannot "fill the rest of the window" with some color, at least > not on the device-independent level of the display engine where I made > the changes. The only way the display engine can dictate colors (and > other face attributes) is by creating glyphs which have these > attributes and adding those glyphs to the current glyph matrix. > > 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. This is butt ugly (and incorrect IMHO) and I had to write my own `font-lock-fontify-syntactically-region' function in order to remove the face property from the return character but I disgress ... 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. I assume that your solution does something equivalent for every virtual buffer line that is missing down to the bottom of the window. And it takes the face property not from the return character but from the remapped default face. Apart from that why do you need a solution from R2L lines here? 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. martin