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

[Eli Zaretskii]

severity 40821 wishlist
thanks

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 24 Apr 2020 11:56:45 -0400
> 
> All three overlays begin at the same point.  Currently, it seems that margin 
> specs are concatenated in order of increasing priority.  This is likely due 
> to before-strings being concatenated in that order?

The strings are not concatenated, they are displayed one after
another, in the order they are processed by the display engine.

The overlays at a given buffer position are indeed sorted.  First,
before-strings should come before after-strings, and within each class
the overlays are sorted in the order of increasing priority.  Then the
sorted overlays are processed one by one in the sorted order.

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

> Additionally, unlike fringe bitmaps, for which the highest-priority bitmap 
> replaces all others on the same line, there doesn't seem to be a way for 
> higher-priority margin specs to replace lower-priority ones.

First, I don't understand what you say about fringe bitmaps: I don't
think there's any priority associated with those bitmaps, or what am I
missing?

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.

> This issue came up when trying to develop a mode to indicate errors and 
> warnings in the margins (instead of drawing symbols in the fringes).  
> Currently, if a line contains errors and warnings, Flycheck will place 
> multiple overlays on the same line, and the fringe bitmap corresponding to 
> the highest-priority one will be displayed.  But if we put a symbol in the 
> margins instead of the fringes, the symbols won't override each others: 
> instead, they will be concatenated, often in the wrong order (as shown in the 
> attached screenshot).

A simple way of overcoming this problem is to define the overlay
priorities in the reverse order of the Flycheck's error/warning
priorities.  A better solution would be to make the margin wider as
needed, something that should be easy enough (line-number-mode did
that, for example).