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

Previous Next

Full log

Message #25 received at 40821 <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 40821 <at> debbugs.gnu.org
Subject: Re: bug#40821: Margin strings are displayed in reverse order of
 overlay priority (low-priority specs hide high-priority ones)
Date: Sat, 25 Apr 2020 13:21:13 -0400

On 25/04/2020 13.08, Eli Zaretskii wrote:
>> Cc: 40821 <at> debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.