GNU bug report logs - #71282
30.0.50; hl-line overlay priority has no affect

Previous Next

Full log

Message #15 received at 71282-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mohsin Kaleem <mohkale <at> kisara.moe>, 71282-done <at> debbugs.gnu.org
Subject: Re: bug#71282: 30.0.50; hl-line overlay priority has no affect
Date: Sat, 29 Jun 2024 23:10:34 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 71282 notabug
> thanks
>
>> From: Mohsin Kaleem <mohkale <at> 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.

Previous Next

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