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 09:01:07 -0400
> 
> On 25/04/2020 03.58, Eli Zaretskii wrote:
> >> One unfortunate side effect of this is that, when margins are too narrow, 
> >> low-priority margin specs are displayed before high-priority ones, and 
> >> hence high-priority ones are not visible.
> > 
> > Yes, the display margins use this very simple strategy of truncating
> > the stuff that has no margin space to be displayed.  Why can't you
> > compute the width of the margins taking into consideration the size of
> > what you need to display there?
> 
> I only want/need to display one margin indicator — the highest priority one :)

Then why not have your code do that?

> Consider a line with the following contents:
> 
> eee www ewew
> 
> And let's assume that the compiler says this:
> 
> 0-3: error: …
> 4-7: warning: …
> 8-12: error: …
> 8-12: warning: …
> 
> In that case, I don't need 4 indicators in the margin, I want just one 
> (indicating an error). But in the the buffer I'd like 4 overlays to apply 
> error and warning faces (though, since two of them cover the same area, one 
> will not be visible; overlay priorities are used to ensure that the error one 
> will take precedence over the warning one).

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?

> (with-current-buffer (get-buffer-create "*fringes*")
>   (erase-buffer)
>   (delete-all-overlays)
>   (let ((beg (point))
>         (end (progn (insert "test") (point))))
>     (let ((ov-low (make-overlay beg end)))
>       (overlay-put ov-low 'before-string (propertize "low" 'display 
> '(left-fringe right-arrow compilation-info)))
>       (overlay-put ov-low 'priority 10))
>     (let ((ov-mid (make-overlay beg end)))
>       (overlay-put ov-mid 'before-string (propertize "mid" 'display 
> '(left-fringe compilation-warning)))
>       (overlay-put ov-mid 'priority 50))
>     (let ((ov-high (make-overlay beg end)))
>       (overlay-put ov-high 'before-string (propertize "high" 'display 
> '(left-fringe compilation-error)))
>       (overlay-put ov-high 'priority 100)))
>   (pop-to-buffer (current-buffer)))
> 
> 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 should be possible to support this idea of "replacing" margin specs
> > (which seems strange to me, FWIW), given some special display spec,
> > but it would need a separate pass through the overlays, to find those
> > which draw in the margins, and mark the replaced ones as "not to be
> > processed".  But I question the need for such a complexity, when a
> > simpler solution that doesn't require any changes seems to be at hand.
> 
> 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.