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

[martin rudalics]

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