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

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

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

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

Previous Next

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