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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 27 Mar 2012 11:23:28 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: darthandrus@gmail.com, monnier@iro.umontreal.ca, 
>  cyd@stupidchicken.com, 11068@debbugs.gnu.org
> 
> Earlier you said
> 
>    "No, the return character has no face, and in fact it has no glyphs."
> 
> and I stubbornly believe that it has a face I can specify, that face has
> an effect on what I see on the screen and apparently even produces a
> stretch glyph I can see.

That's my sloppy wording, sorry.  I meant to say that a newline has no
face _on_display_, because it simply isn't displayed.  It certainly
has a face _in_the_buffer_, which I believe is what you mean.

>  > 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.
> 
> Fully agreed.  But since I switch faces back immediately _after_ the
> newline character it does not affect visible characters but only what
> appears between them.

Right.

> But some part of the text is IMO confusing: In
> 
>       "Normally, the cursor is displayed at the end of any overlay and
>       text property strings present at the current buffer position."
> 
> I understand that an "overlay string" is a before- or after-string or a
> display property string.  But what is a "text property string"?  A
> display property of the text?

Yes, a `display' text property on buffer text.

>       "it specifies the number of buffer's
>       character positions associated with the overlay string"
> 
> clashes with my understanding that this number is already specified by
> the start and end position of the overlay.

That's because you think that the code which positions the cursor has
the overlay in hand to get this information.  But that assumption is
false: the code in question, which needs this property on overlay
strings (set_cursor_from_row) doesn't know what overlay produced the
glyphs in the glyph rows it considers as candidates for cursor
positioning.  All it has is the glyphs, whereby each glyph includes a
reference to the object from which it came.  For glyphs that came from
an overlay string, that object is the string, but the information
about the overlay where the string came from is lost.  By putting the
integer property on the string itself, you allow the
cursor-positioning code to find out how many buffer positions are
covered by the overlay string, without knowing what overlay is that.

>       "this way,
>       Emacs will display the cursor on the character with that property
>       regardless of whether the current buffer position is actually
>       covered by the overlay."
> 
> doesn't make it clearer for me because what is "the character with that
> property" and what is "the current buffer position" here?

"the character" is the one from the overlay string on which you put
the `cursor' property; "current buffer position" is point (which
normally determines where to display the cursor).

> I tried to play around with it but don't see what this means for an
> overlay with a display, before- or after-string property.  So the
> fact that overlays with such a property are affected by the `cursor'
> property remains obscure to me after reading this text.

It's a hard issue to explain, and I obviously failed.  You can see
this feature in action in cua-rectangle; after you play with it,
perhaps you could suggest how to improve the documentation.