GNU bug report logs - #20254
25.0.50; `face' overlays with equal priority at the same location

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20254 in the body.
You can then email your comments to 20254 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; `face' overlays with equal priority at the same location
Date: Fri, 3 Apr 2015 14:44:49 -0700 (PDT)

I add a new overlay with a given `face' value to some text in a buffer.
I add another overlay with a different `face' to the same text.

The two overlays have the same `priority' value.  The appearance
presumably follows what rule?  There is this description in (elisp)
`Overlay Properties', but it covers only the case where different
priorities are involved:

  For the `face' property, the higher priority overlay's value does not
  completely override the other value; instead, its face attributes
  override the face attributes of the lower priority `face' property.

I do the same thing to the same sequence of chars appearing elsewhere in
the same buffer.  The appearance is sometimes the same and sometimes
different.  One of the two faces "wins", it seems, but perhaps with more
testing I would find that there is indeed some face merging(?).  But
in any case, which one wins seems to be arbitrary (random).

If I have several such overlays, each with a different face, at the same
set of places, different ones seem to "win" here and there, again,
seemingly arbitrarily.

If I check `overlays-at' and `C-u C-x =', the overlays listed at each
place are the same, and in the same order.  (They were added to the
locations in sequence, i.e., overlays with a given face were added to
all locations, then overlays with the next face were added to the same
locations, etc.)

Is there a rule behind this behavior?  Can users control which overlay
among several with the same priority "wins"?  It doesn't seem to be the
first or last created, and I haven't found any other rule behind the
behavior either.

Note that the context is not one where I want to use different
priorities.  I'm just asking about the case where multiple overlays
apply to a given sequence of text, and they have the same priority but
different `face' property values.

Is this a bug?  Or could an enhancement be made, to make the behavior
predictable and controllable?

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm <at> gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 20254 <at> debbugs.gnu.org
Subject: Re: bug#20254: 25.0.50;
 `face' overlays with equal priority at the same location
Date: Fri, 03 Apr 2015 18:14:54 -0400

> Is there a rule behind this behavior?

If an overlay is nested inside another, then it takes precedence.
If neither is nested in the other then the precedence is not documented
(IIRC it's arbitrarily taken to be "the one that's closest to
point-min", and if start and end at the same position, then the
precedence depends on the 100% arbitrary addresses of the overlays in
memory).


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20254 <at> debbugs.gnu.org
Subject: RE: bug#20254: 25.0.50; `face' overlays with equal priority at the
 same location
Date: Fri, 3 Apr 2015 15:24:56 -0700 (PDT)

> > Is there a rule behind this behavior?
> 
> If an overlay is nested inside another, then it takes precedence.
> If neither is nested in the other then the precedence is not documented
> (IIRC it's arbitrarily taken to be "the one that's closest to
> point-min", and if start and end at the same position, then the
> precedence depends on the 100% arbitrary addresses of the overlays in
> memory).

In the case I described, the overlays are on exactly the same positions
(they coincide), so the last phrase applies, apparently: "100% arbitrary
addresses of the overlays in memory".

Any chance this implementation could be revisited, to do something
regular - predictable and user-manipulable?  Or would that be too costly
in terms of performance?  If it is feasible then please consider this
to be such an enhancement request.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 20254 <at> debbugs.gnu.org
Subject: Re: bug#20254: 25.0.50;
 `face' overlays with equal priority at the same location
Date: Fri, 03 Apr 2015 21:07:13 -0400

> Any chance this implementation could be revisited, to do something
> regular

Without explicit priority information, we have no data on which to base
the ordering.  We use the overlays' memory address because it does
the job.

> - predictable and user-manipulable?

That's what the `priority' property is for.


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20254 <at> debbugs.gnu.org
Subject: RE: bug#20254: 25.0.50; `face' overlays with equal priority at the
 same location
Date: Fri, 3 Apr 2015 18:55:34 -0700 (PDT)

> > Any chance this implementation could be revisited, to do something
> > regular
> 
> Without explicit priority information, we have no data on which to base
> the ordering.

Order of creation.  Newer replaces or dominates older.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 20254 <at> debbugs.gnu.org
Subject: Re: bug#20254: 25.0.50;
 `face' overlays with equal priority at the same location
Date: Fri, 03 Apr 2015 22:48:33 -0400

>> > Any chance this implementation could be revisited, to do something
>> > regular
>> Without explicit priority information, we have no data on which to base
>> the ordering.
> Order of creation.  Newer replaces or dominates older.

We don't keep track of order of creation.  So this would require adding
a counter to every overlay (which in turns means increasing the size of
overlay and marker objects from 6words to 8words).
Doesn't seem worth the trouble, since while it does provide some form of
reproducibility, it doesn't give much control.


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20254 <at> debbugs.gnu.org
Subject: RE: bug#20254: 25.0.50; `face' overlays with equal priority at the
 same location
Date: Fri, 3 Apr 2015 20:02:07 -0700 (PDT)

> >> > Any chance this implementation could be revisited, to do something
> >> > regular
> >> Without explicit priority information, we have no data on which to base
> >> the ordering.
> > Order of creation.  Newer replaces or dominates older.
> 
> We don't keep track of order of creation.  So this would require adding
> a counter to every overlay (which in turns means increasing the size of
> overlay and marker objects from 6words to 8words).
> Doesn't seem worth the trouble, since while it does provide some form of
> reproducibility, it doesn't give much control.

OK.  Thanks for thinking about it, anyway.

Previous Next

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