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 12:51:52 -0400
> 
> On 25/04/2020 10.04, Eli Zaretskii wrote:
> >> I only want/need to display one margin indicator — the highest priority 
> >> one :)
> > 
> > Then why not have your code do that?
> 
> It's quite complicated: every time I add a new overlay (they arrive 
> asynchronously, not all at once), I need to check for others on the same line 
> and adjust the symbols.  Every time the text is changed, I need to rescan the 
> current line and adjust the overlay properties.

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".

> > It is your Lisp program that puts these overlays, isn't it?  Why
> > cannot it put only one overlay, the one you want to be displayed in
> > this case?
> 
> Because both are needed: for example, when the point is on ewew, the 
> help-echo will be the concatenation of both.  Similarly, when the user 
> browses the error list in a separate buffer, highlighting one error will 
> light up the corresponding portion of the buffer.  Additionally, users can 
> filter errors, hiding certain overlays.

You are talking about aspects of the overlay other than the margin
display.  So leave the other overlays, but remove the margin display
spec from them as needed.

> >> I thought this would show a fringe icon in compilation-error face, because 
> >> of the higher priority of the corresponding overlay.  It doesn't.
> >> Should I report this as a separate issue?
> > 
> > Why is that an issue?  You in effect invoke undefined behavior, and
> > the result is not outlandish, IMO.
> 
> It is: the buffer shows the face of one overlay and the icon of another one.

As expected: faces are merged, but fringe bitmaps aren't.

> >> Widening the margin isn't a working solution for this case, but displaying 
> >> the margin specs in order of increasing priority would work.  However, 
> >> wouldn't that require a second pass as well?  That is, if margin specs 
> >> were sorted by priority before being inserted, it would work (it wouldn't 
> >> matter that there are multiple instead of one, since the most important 
> >> one would be first).
> > 
> > Now I'm confused: the overlays are already being sorted by the display
> > engine, and displayed in the order of increasing priority, as I
> > explained in my original message.
> 
> The margin specs are displayed in order of decreasing priority, as far as I 
> can tell: first the one coming from the overlay with the lowest priority, 
> then the next one, etc.

What you described is actually the order of _increasing_ priority.  Or
am I confused?