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 #23 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 13:59:00 -0800
[Message part 1 (text/plain, inline)]
> 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.
[Message part 2 (text/html, inline)]

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

Previous Next


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