bug#1222: overlay display inherits face properties from buffer

[Eli Zaretskii]

tags 1222 notabug
thanks

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 09:01:13 +0200
> Cc: 1222@debbugs.gnu.org
> 
> Glenn Morris <rgm@gnu.org> writes:
> 
> > This issue also affects before- and after-strings, albeit in slightly
> > different ways:
> >
> > Example:
> >
> > (let ((buff (generate-new-buffer "overlay test"))
> >       o)
> >   (with-current-buffer buff
> >     (insert (propertize "text" 'face '(:background "red")))
> >     (setq o (make-overlay (point-min) (point-max)))
> >     (overlay-put o 'display "display")
> >     (overlay-put o 'before-string "before-string")
> >     (overlay-put o 'after-string "after-string")
> >     (insert (propertize "more" 'face '(:background "green")))
> >     (pop-to-buffer buff)))
> >
> > "before-string" and "display" have a red background, "after-string"
> > has a green background.
> >
> > Ideally, face properties should not be inherited from the buffer in
> > this way.
> 
> Hm...  is this the same as bug#25348?  If so, it was decided there that
> this was behaviour as designed, I think.

No, it isn't related to bug#25348.  But it's "as designed"
nonetheless: the display engine always merges all the sources of the
face information relevant to the current buffer position.  This is
documented in the ELisp manual, see the beginning of the node
"Displaying Faces" (I believe this wasn't documented at the time this
bug was filed).

IOW, what is reported here is the expected behavior, that's how the
code was designed and implemented.

P.S. The original report says "inherits face properties from the
following buffer text", but the "following" part is only accurate when
referring to how text appears on display.  The Lisp code in the report
clearly puts the red background on the text "covered" by the overlay,
so that background affects the buffer position(s) where the overlay is
set up.