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

[Clément Pit-Claudel]

On 25/04/2020 13.36, Eli Zaretskii wrote:
>> 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?

I think we're getting too closely attached to a specific use case.  There's a 
simple problem with the margins: you put two overlays on one line, they both 
have margin specs, they both have faces with a foreground.  One is priority 
100, the other 0.  The margin is 1-character wide.  Then you see just one thing 
in the margin: the spec from the low-priority overlay.  And you see one face in 
the buffer: the one from the high priority overlay.

I'm saying it doesn't make much sense.  Same for the fringes.  Of course, it's 
not specified, so nowhere have committed to this broken behavior or to any 
other beahvior at this point.
But that doesn't make it less broken: the one mechanism we have for determining 
which overlay wins (priorities) applies in reverse for the fringes and the 
margins.
Maybe what we need is a more general mechanism for deciding which spec wins, if 
you don't think priority is the right 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.
> …
> We shouldn't complicate it more where Lisp programs
> which create the overlays can DTRT instead.

Then TRT sounds a lot like reimplementing a part of the display engine in 
ELisp: iterating over overlays on each line, sorting them by priority, taking 
their margin specs and fringes, determining the highest priority one, and 
displaying that in the margin/fringe, for each modified line, after each 
command.  And ideally, doing that lazily too, to avoid doing work on the whole 
buffer at once and slowing editing down.  Isn't that the job description of the 
display engine?

Thanks for your help,
Clément.