> Let OA and OB denote two different empty overlays residing at the same
> buffer position. If OB has a before-string and OA has an after-string
> the after-string is displayed in front of the before-string. The
> barrier sketched above would handle this in a more intuitive way.
This is by design -- this is explicitly documented in the source code:
I think this is the right behavior in most cases, but there is one
cases where I think the opposite order might be better. That this the
case where a character inserted at that point would belong to both
overlays.
So perhaps this
1. All after-strings come in front of before-strings, except
when they come from the same overlay.
should be changed to this:
1. The overall order is as follows:
All after-strings from overlays whose end-markers don't
advance, and text properties that are not rear-sticky,
All before-strings from overlays whose beginning-markers don't
advance, and text properties that are front-sticky,
All after-strings from overlays whose end-markers do advance,
and text properties that are rear-sticky,
All before-strings from overlays whose beginning-markers don't
advance, and text properties that are not front-sticky,
At least, it seems to be right in all the cases as far as I can see.
Worse, the following paragraph seems to indicate that the priority is
not about ordering multiple after- and before-strings, but selecting
just ONE before- and/or after-string to show.
Is that what the code really does?
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
