GNU bug report logs - #25348
`display` property faces are prioritized above overlays

Previous Next

Package: emacs;

Reported by: Travis Foster <tsfoster <at> mtu.edu>

Date: Tue, 3 Jan 2017 22:22:02 UTC

Severity: minor

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 25348 <at> debbugs.gnu.org (full text, mbox):

From: Travis Foster <tsfoster <at> mtu.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, 25348 <at> debbugs.gnu.org
Cc: Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#25348: `display` property faces are prioritized above overlays
Date: Wed, 4 Jan 2017 11:25:54 -0800
[Message part 1 (text/plain, inline)]
> Emacs uses the face from the overlay only for text to which this
> overlay is applied.  The display string is therefore using its own
> face definitions, which completely override those from the hl-line
> overlay.

I just figured that the overlay applies to a range of text, and the
replacement text is within that range ... so it seems like it should be
affected. I guess not, though. So what you're saying is, since the
replacement text is not technically part of the buffer text, it doesn't
count as being within the range of the overlay, and it isn't affected by
the overlay at all? But that's not the case either, because as you also
stated, face attributes from the overlay are applied to the display string,
as long as the display string doesn't already specify those attributes. So,
it seems that the overlay is applied to the display string, but it just
takes a lower priority than the display string's text properties. If that
was the design, that's fine, but it does conflict with the documentation
stating that overlays always take priority over text properties.

I haven't looked at the code for this, so I might be wrong, but what
appears to be happening is this:
1. The overlay is applied to the buffer text, and the overlay face takes
priority over the buffer text's faces
2. If the overlay had a display property, that would take priority over the
buffer text's display property, but since the overlay has no such property,
this doesn't happen
3. After the overlay is applied, the display property is applied, and its
faces take priority over the existing faces, including those supplied by
the overlay

So the priority goes: display property faces > overlay faces > buffer
faces. Am I on the right track?
[Message part 2 (text/html, inline)]

This bug report was last modified 5 years and 238 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.