[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42552: 28.0.50; Overlay 'face' property doesn't set the "underlying
bug#42552: 28.0.50; Overlay 'face' property doesn't set the "underlying face" for 'after-string'
Fri, 07 Aug 2020 08:42:12 +0300
> Cc: email@example.com
> From: Dmitry Gutov <firstname.lastname@example.org>
> 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
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:
> (insert (propertize "abc"
> '((:background "green" :extend t)
> ( :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?