bug#42552: 28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string'

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 42552@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 7 Aug 2020 02:16:12 +0300
> 
> On 05.08.2020 17:58, Eli Zaretskii wrote:
> 
> >> Should the "overlay string" obey the underlying face, though? It doesn't
> >> obey the 'face' property, like you explained. Seems inconsistent.
> > 
> > Emacs always worked this way, so changing it now is probably a big
> > deal.  AFAIU, the reason for this behavior is so that overlay strings
> > which specify no faces use the same face as the surrounding text.
> > Which sounds reasonable.
> 
> Do you imagine creating a better consistency the other way (by having 
> the 'face' property affect overlay strings) would be as likely to create 
> problems?

That's largely orthogonal, as most overlays don't specify 'face'
AFAIK.  But yes, this could also be a problem after so many years of
disregarding it.  If we really want something like that, perhaps a
separate new property (like 'overriding-face') would be a better way.

> >> But it should obey :extend set to nil, shouldn't it?
> > 
> > It does, but :extend nil doesn't override :extend t, it just says that
> > the face with a nil :extend attribute should not be considered when
> > computing the face for the empty space past EOL.
> 
> BTW, are there other attributes with a similar property?

Perhaps not, I haven't checked.

> For example, I find that I have to add (:inverse-video nil)
> explicitly to the computed face which would be appended to the
> overlay string's 'face' properties.
> 
> Otherwise, the newlines are still "extended" with the "inverse video" 
> effect. Try this for an example:
> 
> 1. Eval:
> 
> (with-silent-modifications
>    (insert (propertize "abc"
>                        'font-lock-face
>                        '((:background "green" :extend t)
>                          default
>                          ( :inverse-video t
>                            :foreground "yellow"
>                            :extend t)))))
> 
> 2. C-j
> 
> The "extended" newline is yellow.

That's expected due to face-merging, no?

> I'll try to implement this all as suggested, and will come back after.

Should we close this bug or keep it open?