bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones)

[Eli Zaretskii]

> Cc: 40821@debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 25 Apr 2020 13:21:13 -0400
> 
> > Yes, but is it reasonable to ask the display engine to figure that out
> > for you?  You are talking about something that is clearly application
> > logic; other applications might want some other logic to have other
> > overlays "win".
> 
> I think it is reasonable: we already have a notion of overlays "winning", 
> namely their priority.

But you want to change that, based I don't really understand on what?

The handling of overlays by their priorities is mainly for when each
overlay is created by a different Lisp program, when coordination is
hard or impossible.  This is not the case here.

> > As expected: faces are merged, but fringe bitmaps aren't.
> 
> Yes, which is the outlandish part :)

I don't think I see it that way.

> > What you described is actually the order of _increasing_ priority.  Or
> > am I confused?
> 
> Of, yes, you're completely right; sorry for mixing up the terms.
> I meant to say that, if highest-priority overlays were displayed first in the 
> margin, then on narrow margins specs from high-priority overlays would take 
> precedence.

And we are right back to square one...

I can only reiterate my suggestion: don't rely on the display engine
to solve the problems in such cases.  The best solution is for the
Lisp program to apply its logic and put only the overlays it needs.

I'm not saying this just out of stubbornness.  Handling of overlays is
a notoriously complex part of the display engine, because they
interact with faces, invisible properties, and display properties in
complicated ways.  We shouldn't complicate it more where Lisp programs
which create the overlays can DTRT instead.