* bug#25348: `display` property faces are prioritized above overlays
@ 2017-01-03 22:17 Travis Foster
2017-01-03 22:29 ` Drew Adams
0 siblings, 1 reply; 10+ messages in thread
From: Travis Foster @ 2017-01-03 22:17 UTC (permalink / raw)
To: 25348
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
When I do the following (for example):
(put-text-property (point) (1+ (point)) 'display (propertize "." 'face
'header-line))
The character at point becomes a dot with a gray background. If I then
enable hl-line-mode, the line turns green, as expected. However, the dot
still has a gray background; it does not turn green with the rest of the
line.
It appears that hl-line-mode uses an overlay to highlight the line. From
the overlay documentation, "Currently, all overlays take priority over text
properties." But it seems like in this case, the display text property is
taking priority over the the overlay. Since I'm embedding the face into the
display string, I expect it to take priority over any faces that are
applied to the text, but not over any overlays which affect it.
[-- Attachment #2: Type: text/html, Size: 913 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-03 22:17 bug#25348: `display` property faces are prioritized above overlays Travis Foster
@ 2017-01-03 22:29 ` Drew Adams
2017-01-03 22:52 ` Travis Foster
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2017-01-03 22:29 UTC (permalink / raw)
To: Travis Foster, 25348
> When I do the following (for example):
> (put-text-property (point) (1+ (point))
> 'display (propertize "." 'face 'header-line))
...
> But it seems like in this case, the display text property
> is taking priority over the the overlay.
You are using a "replacing" `display'-property spec.
See (elisp) `Replacing Specs'.
http://www.gnu.org/software/emacs/manual/html_node/elisp/Replacing-Specs.html
Your text that has the property is entirely replaced (for display)
by what is specified for property `display'.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-03 22:29 ` Drew Adams
@ 2017-01-03 22:52 ` Travis Foster
2017-01-04 16:06 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Travis Foster @ 2017-01-03 22:52 UTC (permalink / raw)
To: Drew Adams, 25348
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Yes, the text in the buffer is replaced by its display text, with the face.
Then, I would expect the overlay to apply to all the text on the line,
including the replacement text. Since the properties in overlays are
supposed to take priority over the properties in the buffer itself, I don't
think it makes sense for the replacement to take priority over the
overlay. Is that wrong? It seems that the replacement should occur, and
then the resulting text should be modified further by the overlay.
On Tue, Jan 3, 2017 at 2:29 PM, Drew Adams <drew.adams@oracle.com> wrote:
> > When I do the following (for example):
> > (put-text-property (point) (1+ (point))
> > 'display (propertize "." 'face 'header-line))
> ...
> > But it seems like in this case, the display text property
> > is taking priority over the the overlay.
>
> You are using a "replacing" `display'-property spec.
> See (elisp) `Replacing Specs'.
> http://www.gnu.org/software/emacs/manual/html_node/elisp/
> Replacing-Specs.html
>
> Your text that has the property is entirely replaced (for display)
> by what is specified for property `display'.
>
[-- Attachment #2: Type: text/html, Size: 1677 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-03 22:52 ` Travis Foster
@ 2017-01-04 16:06 ` Eli Zaretskii
2017-01-04 19:25 ` Travis Foster
2019-09-29 16:22 ` Lars Ingebrigtsen
0 siblings, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2017-01-04 16:06 UTC (permalink / raw)
To: Travis Foster; +Cc: 25348
> From: Travis Foster <tsfoster@mtu.edu>
> Date: Tue, 3 Jan 2017 14:52:26 -0800
>
> Yes, the text in the buffer is replaced by its display text, with the face. Then, I would expect the overlay to apply
> to all the text on the line, including the replacement text. Since the properties in overlays are supposed to take
> priority over the properties in the buffer itself, I don't think it makes sense for the replacement to take priority
> over the overlay. Is that wrong?
Drew is right: the priority of overlays over text properties only
comes into play when both text properties and overlays are set on the
same region of text. In your case, the 'face' property is put on a
display string, whereas the hl-line overlay is on buffer text. So
priority considerations don't apply here.
> It seems that the replacement should occur, and then the resulting
> text should be modified further by the overlay.
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.
If you define a face for the display string that only specifies a
foreground color, then Emacs will use the hl-line overlay for the
background color.
This is normal operation of the Emacs display engine, it has been like
that since Emacs 21. IOW, this is not a bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-04 16:06 ` Eli Zaretskii
@ 2017-01-04 19:25 ` Travis Foster
2017-01-04 19:55 ` Eli Zaretskii
2019-09-29 16:22 ` Lars Ingebrigtsen
1 sibling, 1 reply; 10+ messages in thread
From: Travis Foster @ 2017-01-04 19:25 UTC (permalink / raw)
To: Eli Zaretskii, 25348
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
> 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?
[-- Attachment #2: Type: text/html, Size: 1896 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-04 19:25 ` Travis Foster
@ 2017-01-04 19:55 ` Eli Zaretskii
2017-01-04 21:59 ` Travis Foster
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2017-01-04 19:55 UTC (permalink / raw)
To: Travis Foster; +Cc: 25348
> From: Travis Foster <tsfoster@mtu.edu>
> Date: Wed, 4 Jan 2017 11:25:54 -0800
> Cc: Drew Adams <drew.adams@oracle.com>
>
> 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.
The replacement text comes from a string, not from the buffer, so it
is NOT within the range of buffer text to which the overlay is applied.
> 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?
Yes.
> 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.
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.)
> 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.
That's your interpretation, but it is incorrect. As a matter of fact,
the priority is not applicable in this case, because the two faces are
applied to two different objects: one is buffer text, the other is the
text of the display string.
> it does conflict with the documentation stating that overlays always
> take priority over text properties.
Not in my view and interpretation, no.
> 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
That's not how the code works, if you want to talk about the
implementation. What actually happens is this:
. The display engine displays the buffer text with the overlay face
applied, one character at a time, until it bumps into the display
string.
. The display engine then stops displaying buffer text, pushes its
internal state onto a stack, then starts displaying the display
string, using the face of that string. If the face doesn't
specify all the face attributes, it is merged with the face of the
"underlying" buffer text, in this case the face of the hl-line
overlay.
. When the text of the display string is exhausted, the display
engine pops the previous state from the stack, jumps to buffer
position beyond the text replaced by the display string, and
continues displaying buffer text using the overlay face.
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-04 19:55 ` Eli Zaretskii
@ 2017-01-04 21:59 ` Travis Foster
2017-01-05 16:27 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Travis Foster @ 2017-01-04 21:59 UTC (permalink / raw)
To: Eli Zaretskii, 25348
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 2422 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-04 21:59 ` Travis Foster
@ 2017-01-05 16:27 ` Eli Zaretskii
2017-01-05 18:10 ` Travis Foster
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2017-01-05 16:27 UTC (permalink / raw)
To: Travis Foster; +Cc: 25348
> From: Travis Foster <tsfoster@mtu.edu>
> Date: Wed, 4 Jan 2017 13:59:00 -0800
> Cc: Drew Adams <drew.adams@oracle.com>
>
> 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.
As I already mentioned, if your face for the display string doesn't
specify a background color, the hl-line background color will be used.
If that's not an option, perhaps you could do that dynamically, by
changing the face of the display string whenever the hl-line overlay
is on the line where you have your display string?
Or maybe someone else will have more clever ideas.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-05 16:27 ` Eli Zaretskii
@ 2017-01-05 18:10 ` Travis Foster
0 siblings, 0 replies; 10+ messages in thread
From: Travis Foster @ 2017-01-05 18:10 UTC (permalink / raw)
To: Eli Zaretskii, 25348
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
> As I already mentioned, if your face for the display string doesn't
> specify a background color, the hl-line background color will be used.
Yeah, I don't think that's an option. My use case is, I'm coloring tab
characters with different colors for multiple segments within the
character. So to do that, I'm setting the tab's display property to a
number of spaces equal to the width of the tab, and then I'm coloring the
spaces separately. But, the entire point is that I'm coloring whitespace,
so it has to set the background color.
> If that's not an option, perhaps you could do that dynamically, by
> changing the face of the display string whenever the hl-line overlay
> is on the line where you have your display string?
That's a possibility. I'll have to think about that.
Thanks for the help.
[-- Attachment #2: Type: text/html, Size: 958 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#25348: `display` property faces are prioritized above overlays
2017-01-04 16:06 ` Eli Zaretskii
2017-01-04 19:25 ` Travis Foster
@ 2019-09-29 16:22 ` Lars Ingebrigtsen
1 sibling, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-29 16:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Travis Foster, 25348
Eli Zaretskii <eliz@gnu.org> writes:
> This is normal operation of the Emacs display engine, it has been like
> that since Emacs 21. IOW, this is not a bug.
I think this was the conclusion here, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-09-29 16:22 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-03 22:17 bug#25348: `display` property faces are prioritized above overlays Travis Foster
2017-01-03 22:29 ` Drew Adams
2017-01-03 22:52 ` Travis Foster
2017-01-04 16:06 ` Eli Zaretskii
2017-01-04 19:25 ` Travis Foster
2017-01-04 19:55 ` Eli Zaretskii
2017-01-04 21:59 ` Travis Foster
2017-01-05 16:27 ` Eli Zaretskii
2017-01-05 18:10 ` Travis Foster
2019-09-29 16:22 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).