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

[Eli Zaretskii]

> Date: Sun, 25 Mar 2012 21:19:43 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: darthandrus@gmail.com, monnier@iro.umontreal.ca, 
>  cyd@stupidchicken.com, 11068@debbugs.gnu.org
> 
>  > 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.
> 
> 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.

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.

>  >> And it takes the face property not from the return character but
>  >> from the remapped default face.
>  >
>  > No, the return character has no face,
> 
> 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.

> 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.

> 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.

> 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.