bug#11068: 24.0.94; Face-remapped background does not extend to end of window

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 26 Mar 2012 09:05:43 +0200
> From: martin rudalics <rudalics@gmx.at>
> 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.