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: Mon, 26 Mar 2012 15:32:27 -0400 Message-ID: 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> <4F701547.6070003@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1332790442 9481 80.91.229.3 (26 Mar 2012 19:34:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2012 19:34:02 +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 Mon Mar 26 21:33:59 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 1SCFfy-0005fl-1Y for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Mar 2012 21:33:58 +0200 Original-Received: from localhost ([::1]:41743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFfx-0004ah-Br for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Mar 2012 15:33:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFfu-0004aQ-1m for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 15:33:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCFfr-0001j4-V3 for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 15:33:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCFfr-0001iz-Rj for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 15:33:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SCGA2-0000eR-5Q for bug-gnu-emacs@gnu.org; Mon, 26 Mar 2012 16:05:02 -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: Mon, 26 Mar 2012 20:05: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.13327922782472 (code B ref 11068); Mon, 26 Mar 2012 20:05:01 +0000 Original-Received: (at 11068) by debbugs.gnu.org; 26 Mar 2012 20:04:38 +0000 Original-Received: from localhost ([127.0.0.1]:40058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCG9I-0000dS-ST for submit@debbugs.gnu.org; Mon, 26 Mar 2012 16:04:37 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:60748) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCG8j-0000cT-Qq for 11068@debbugs.gnu.org; Mon, 26 Mar 2012 16:04:15 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1SCFeV-0004V4-HX; Mon, 26 Mar 2012 15:32:27 -0400 In-reply-to: <4F701547.6070003@gmx.at> (message from martin rudalics on Mon, 26 Mar 2012 09:05:43 +0200) 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:58171 Archived-At: > Date: Mon, 26 Mar 2012 09:05:43 +0200 > From: martin rudalics > CC: darthandrus@gmail.com, monnier@iro.umontreal.ca, > cyd@stupidchicken.com, 11068@debbugs.gnu.org > > >> 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. Well, strictly speaking, it's a space only on a TTY. On GUI terminals, it's a special glyph that just looks like a space. > 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? The point I'm stubbornly trying to make is that what matters for the face extension is the last face loaded by the display iterator, _not_ the face of the newline or any other character. The display iterator changes faces at so-called "stop positions", where buffer contents of text properties or overlays specify a different face. Once a face is resolved and loaded, it stays recorded in the iterator and affects every glyph we deliver until another "stop position" is encountered. Your code simply forces the display iterator to switch faces after the last character of a line. That's it. The newline doesn't enter this game at any point, because it is never drawn. IOW, what's important is the _position_ where the new face gets in effect, not what character it is on. > >> (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 ... This _is_ described, but not in the section about overlays, because `cursor' is a text property you should put on `display' property strings or on overlay strings. So this is described in "Special Properties", and the description does mention overlay strings. Maybe an index entry should be added that starts with "overlay"; perhaps you could suggest such an entry.