> If the face of the display string doesn't specify the background
> color, the only sensible thing to do is to use the background of the
> "underlying" buffer text. (Note that in this case the issue of
> priority doesn't arise either, because only one of the sources
> specifies the background color.)
Alright ... and the "underlying" face it appears to use is the one applied to the first character of the replacee text. That makes sense, I guess.
> > So the priority goes: display property faces > overlay faces > buffer faces. Am I on the right track?
>
> No, because the priority is not being considered in this situation.
> The priority is only considered when the same text has both text
> properties that specify a face and one or more overlays that also
> specify a face.
Apologies, I was using 'priority' in the more general sense of "which faces will show up on the screen", rather than in the implementation sense of the overlay `priority` property and priority calculation. Perhaps I should use another word instead, like 'precedence' or something.
> > it does conflict with the documentation stating that overlays always
> > take priority over text properties.
>
> Not in my view and interpretation, no.
But it appears to, I think. All I'm saying here is that, based entirely on the wording of the documentation and with no insight into the implementation, the most intuitive interpretation is that the display text property should be expanded first, and then the faces and properties from the overlay should be applied on top of that. I realize that this wouldn't quite work, since trying to apply an overlay on top of already replaced text would be problematic, but it's still surprising that the precedence for faces isn't [overlay display string > overlay text > buffer display string > buffer text]. I don't know, maybe I'm wrong.
So, alright, this isn't a bug. What if I don't want this behavior, though? Is there anything I can do to my display properties so that they don't show through overlays? I sort of doubt it at this point, but I might as well ask.