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: Mon, 26 Mar 2012 09:05:43 +0200 Message-ID: <4F701547.6070003@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> <4F6F1574.2090904@gmx.at> <83r4wgsii6.fsf@gnu.org> <4F6F6FCF.30806@gmx.at> <837gy8s64w.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 1332745627 2908 80.91.229.3 (26 Mar 2012 07:07:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2012 07:07:07 +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 Mon Mar 26 09:07:06 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 1SC419-0006QR-3j for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Mar 2012 09:07:03 +0200 Original-Received: from localhost ([::1]:49184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC418-0001L2-3Z for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Mar 2012 03:07:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC414-0001Ke-5K for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 03:06:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SC411-0004Sx-Hm for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 03:06:57 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SC411-0004Sb-Df for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 03:06:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SC4V8-0004sH-KN for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 03:38: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: Mon, 26 Mar 2012 07:38:02 +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.133274743518675 (code B ref 11068); Mon, 26 Mar 2012 07:38:02 +0000 Original-Received: (at 11068) by debbugs.gnu.org; 26 Mar 2012 07:37:15 +0000 Original-Received: from localhost ([127.0.0.1]:39031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SC4UM-0004r9-CY for submit@debbugs.gnu.org; Mon, 26 Mar 2012 03:37:15 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:60526) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SC4U5-0004qT-4r for 11068@debbugs.gnu.org; Mon, 26 Mar 2012 03:37:12 -0400 Original-Received: (qmail invoked by alias); 26 Mar 2012 07:05:47 -0000 Original-Received: from 62-47-37-221.adsl.highway.telekom.at (EHLO [62.47.37.221]) [62.47.37.221] by mail.gmx.net (mp039) with SMTP; 26 Mar 2012 09:05:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+FZoRD5kmFBlb0Nim4Cy/QynIdKEySvbqqCb1FaY 30DYKtyT43E9mb In-Reply-To: <837gy8s64w.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:58157 Archived-At: >> So you do use an established mechanism but for the fact that these lines >> exist only virtually. Or am I missing something? > > I don't understand what you mean by "exist only virtually". We are > not talking about lines, we are talking about glyph matrices. A glyph > matrix has at least one glyph for each screen line, no matter if there > is or isn't text on these lines; this includes empty lines beyond BOB. With "virtual" I tried to describe the presence of a (space) character on the screen which has no correspondence to a "real" character in a buffer. > The established mechanism I used was invented for extending the > (non-default) face of the last character of a line all the way to the > right margin of the window. I made it do double duty for R2L lines, > because these need a stretch glyph at their left, so that the > device-specific drawing code could still draw left to right. Then I > made it do triple duty when the default face is remapped, by adding > stretch glyphs even on L2R lines beyond EOB. All it took was to > slightly tweak the conditions under which the function > extend_face_to_end_of_line is called, and what it does as part of its > job. That's what I thought. Thanks for the precise explanation. >> But when drawing the stretch glyph at a non-EOB line end the display >> engine does use the face of the return character. > > Not the face of the return character, but the face of the last glyph > produced for the line. I still can't follow you. For years I use: (defun font-lock-fontify-syntactically-region (start end &optional loudly ppss) "Put proper face on each string and comment between START and END. START should be at the beginning of a line." (let (state face from to lep) (goto-char start) (setq state (or ppss (syntax-ppss start))) (while (progn (when (or (nth 3 state) (nth 4 state)) (setq face (funcall font-lock-syntactic-face-function state)) (setq from (max (nth 8 state) start)) (setq state (parse-partial-sexp (point) end nil nil state 'syntax-table)) (setq to (point)) (save-excursion (goto-char from) (while (< from to) (setq lep (line-end-position)) (if (< lep to) (progn (put-text-property from lep 'face face) (remove-text-properties lep (1+ lep) '(face nil)) ; rear-nonsticky t)) (goto-char (setq from (1+ lep)))) (put-text-property from to 'face face) (setq from to))))) (< (point) end)) (setq state (parse-partial-sexp (point) end nil nil state 'syntax-table))))) (custom-set-faces '(font-lock-comment-face ((((class color) (background light)) (:background "Beige" :foreground "Black")))) '(font-lock-string-face ((t (:foreground "green4")))) '(font-lock-doc-face ((t (:inherit font-lock-string-face :background "grey96"))))) Evaluate these in *scratch* with emacs -Q and redraw. You will see that the background of comments and doc-strings does _not_ extend to the right window margin although the last character on each comment or doc-string line _does_ have that background. Now what constitutes "the last glyph produced" for such a line? That of the last visible character on the buffer line? >> In my `font-lock-fontify-syntactically-region' function I strip all >> face properties from the return character and the rest of the line >> has the default background. > > What that does is force redisplay to change the face at the line > boundary. Normally, the last face used on the line is also used for > the first glyph of the next line. The face of the newline itself has > no direct relation to this. But as you see from my code above, all I do is change the face of the newline character. The faces before and after it remain unchanged. You can easily verify for yourself in a not font-locked buffer: Change the background of one newline character only and the value you specifiy there will be used for drawing the space between the last visible character on the line and the right window margin and for nothing else. >> Couldn't we "clear" using the remapped default color as well? > > That's possible, but it's a much worse design, IMO, because it would > mean this needs to be implemented N times, one each for every terminal > type we support (TTY, X, w32, ns). Worse, there's this: > >> Does "clearing" care about character heights, for example? > > No. It also cannot support faces with a stipple. So this design > isn't really up to the job at all. Aha. This clears things up for me. >> If you do, for example, >> >> (let ((overlay (make-overlay (point-max) (point-max)))) >> (overlay-put overlay 'after-string "\n\n\n\n")) >> >> you can't move to the position before the overlay which makes the whole >> thing worthless. > > Try putting a `cursor' text property on the first newline of the > string, and if that doesn't work, I might agree it's a bug. > Otherwise, Emacs always puts the cursor after the overlay string. Thanks, that works. Now if only this had been described in the overlays manual section ... martin