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.08, Eli Zaretskii wrote:
>> 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".

I think it is reasonable: we already have a notion of overlays "winning", 
namely their priority.

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

Yes, which is the outlandish part :)

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

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.