[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40821: Margin strings are displayed in reverse order of overlay prio
From: |
Clément Pit-Claudel |
Subject: |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
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.
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/24
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones),
Clément Pit-Claudel <=
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Eli Zaretskii, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Dmitry Gutov, 2020/04/25
- bug#40821: Margin strings are displayed in reverse order of overlay priority (low-priority specs hide high-priority ones), Clément Pit-Claudel, 2020/04/25