bug#71282: 30.0.50; hl-line overlay priority has no affect

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 71282 notabug
> thanks
>
>> From: Mohsin Kaleem <mohkale@kisara.moe>
>> Date: Thu, 30 May 2024 23:27:02 +0100
>>
>> Looks like there's no way to give hl-line a higher priority than other
>> text overlays.
>
> Of course there is: use the hl-line-overlay-priority option, like you
> did below.  But the problem you are trying to solve cannot be solved
> by overlay priorities, see below.
>
>> This impacts things like eglot-inlay-hints-mode or
>> overlay-error-string among other modes and has the affect of making
>> hints or annotations from these modes look out of place.
>
> Those 2 examples are not expected to be affected by the priority of
> the hl-line overlay, albeit for different reasons:
>
>   . eglot-inlay-hints-mode overlays have their priorities at 50+, and
>     these overlays display strings (so are similar to your snippet
>     below)
>   . overlay-error-string is not an overlay (despite its confusing
>     name)
>
>> I can reproduce this with something as minimal as:
>>
>> $ emacs -Q
>> $ M-:
>> (progn
>>   (setq hl-line-overlay-priority 10)
>>   (hl-line-mode)
>>   (erase-buffer)
>>   (insert ";; This buffer is for text that is not saved, and for Lisp 
>> evaluation.
>> ;; To create a file, visit it with ‘SPC f f’ and enter text in its buffer.")
>>   (let ((ov (make-overlay (+ (point-min) 2) (+ (point-min) 3))))
>>     (overlay-put ov 'before-string "foo")
>>     (overlay-put ov 'priority 5)))
>>
>> If you move the point to the first line you can see the overlay and its
>> face background completely disregards hl-lines background despite having
>> a lower priority.
>
> This is intended behavior: overlay priority affects only the text to
> which the overlay is applied.  In the above snippet, the overlay is
> applied to buffer text, whereas "foo" is an overlay string, and has
> its own face information (which defaults to the face of the underlying
> buffer text).  So the hl-line overlay's face does not affect the face
> of the before-string.
>
> There's no bug here, only a well-documented behavior.  See the node
> "Displaying Faces" in the ELisp manual for the details.

I'm therefore closing this bug report.