Re: before- and after-string issues

[martin rudalics]

>     Putting `mark' before S and `point' after T highlights the entire
>     overlay but not its after-string.
>
> That in itself might be ok.

Agreed.  But in this case a before-string should not get highlighted
either when the associated overlay is highlighted.  I'd classified such
highlighting intuitive - so far.  Moreover, you would have to consider
the case where a before- or after-string is _completely_ embedded in the
highlighted region.  Not highlighting the string in that case could be
quite irritating.

>     Moreover, A inherits face properties from the character displayed after
>     A and not from the last character of the overlay.  Counterintuitive too.
>
> I don't see why A inherits any properties from characters either before
> or after it.  That seems like a bug.

I believe that a before- or after-string _could_ inherit normal face
(not mouse-face) properties from the face of the associated overlay.
It's a matter of taste whether it should.  If it does, however, it
should inherit properties in an intuititve and symmetric fashion with
respect to the associated overlay.

>
> Normally when we speak of inheriting text properties we mean that you
> insert character C and it gets properties from an adjacent character
> D.  But that doesn't happen here, does it?

No.  But I couldn't - and still can't - think of a better term.
`xfaces.c' calls this "merging".

> Do you actually mean
> that the text of A is displayed in a way controlled by the properties
> of the following character?

That's what this particular point should have been all about.

>
> That seems to be simply a bug.  So I think we don't need to look
> for adding some kind of new features, some kind of "barriers".
> We just need to fix the bug.
>

Barriers would have been useful iff "inheritance" were allowed.  If you
rule out any such inheritance you won't need them.  But note: You will
have to consider before-strings too which did not appear in my report.
Moreover, some strategy will be needed to handle highlighting of before-
and after-strings anyway.  Barriers would have done highlighting and
face inheritance in a uniform way.  And, I didn't think of barriers as
"some kind of new feature" - just a simple and transparent concept
hidden in the depths of `xdisp.c' and `xfaces.c`'.