Re: before- and after-string issues

[Richard Stallman]

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