RE: Nested display strings

[Drew Adams]

> > Don't `display' and `priority' get along well, or can't 
> > they be be made to get along?
> > 
> > We have two overlapping overlays here, and the usual way to 
> > determine what happens when overlays overlap is by looking
> > at their `priority' values (among other things).
> 
> In the example that started this thread, there were no priorities at
> all.

I realize that you said nothing about there being `priority' values present.

My point was that using priorities would normally be a way for users to handle
such conflicts.  That assumes that priorities actually function normally with
overlapping `display' overlays.

> The question is, whether the behavior in that case is
> correct or not.

That is certainly one question.  But not the most important one, to my naive
eyes.  If priorities do in fact work in this context (dunno), then whatever the
answer to your question the user (programmer) should have a way to manipulate
the behavior.

> But even if different priorities were involved, how do they help
> resolve the issue with overlays that have `display' property whose
> value is a string or an image?  These overlay properties _replace_ the
> buffer text, not determine how to display the buffer text.

Reading the doc suggests (to me) that whichever of the overlays at a given
position has higher priority controls the display behavior at that position.
The string or image value of the higher-priority overlay would win at that
position.

That's one naive reading of the doc, and it doesn't mean that there wouldn't be
problems in practice.  You likely wouldn't want different chars of contiguous
text to each display a different image, back and forth!  Still, it seems like
you could control the behavior, given the documented rule, by applying
priorities sanely.  Dunno.

> If the two overlays were covering the same range of buffer positions,
> then we could expect that the overlay with the higher priority would
> "win".

Yes, that's what I was thinking.  And any overlap is "the same range of buffer
positions".  An overlay can cover more than the overlapped range, but within
that overlap range what you say should apply (in principle), no?

> But what to do in the case I presented, where one of the overlays
> covers only a subset of positions covered by the other?  

At any given position there is one overlay or two.  If two, then at that
position the overlay with the higher priority wins (at least that's my reading
of the doc).

If a higher-priority overlay is strictly nested within a lower-priority one,
then I would naively expect the lower one to win outside the overlap and the
higher one to win inside it.

If the higher-priority overlay is the wider one, then I would expect the
lower-priority one never to show.

I would think of this in terms of visual layers (until I discovered that such an
analogy might not always help...).

> How can priorities help in that case?

See above for an attempt.

> If the "shorter" overlay has a higher priority, what to display
> instead of the characters covered only by the "longer" one?

Dunno what you mean by "instead of the characters covered only by the "longer"
one".  The shorter one only has an effect on the chars that it is applied to,
no?  What am I missing (probably a lot)?

> Either nothing or you get the duplicate display of
> STRING1 again.  Both alternatives look bad.

What appearance/behavior is it that you are aiming at?  If someone uses
overlapping overlays then s?he has to decide what happens at the overlap.  Emacs
generally decides this by priority value.  That's a simple approach.  It doesn't
mean you can't end up with "bad" looking displays.

Perhaps give an example of the behavior/appearance that you want to achieve.
It's hard to imagine what might or might not work if we don't know what you're
aiming at.
 
> > If `display' and `priority' can be made to cooperate then 
> > that would be good.
> 
> I don't see how could they; see above.

Ditto - see above.

Again, I'm no expert on this.  I'm just reading the doc and thinking that
overlay priority makes sense in the `display' case also.  (Whether it works in
practice is another story.)

An overlay specifies display characteristics at given buffer positions.  IIUC, a
determination is made (logically at least) at each position as to what should be
displayed for that position (e.g., in place of the char at that position).

I don't have a position on this.  Feel free to ignore if I'm missing the boat.
But from (just) a reading of the doc it doesn't seem so complicated (in
principle).