bug#20254: 25.0.50; `face' overlays with equal priority at the same location

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Drew Adams]

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@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Stefan Monnier]

> 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

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Drew Adams]

> > 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.

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Stefan Monnier]

> 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

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Drew Adams]

> > 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.

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Stefan Monnier]

>> > 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

bug#20254: 25.0.50; `face' overlays with equal priority at the same location

[Drew Adams]

> >> > 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.