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

Previous Next

Full log

Message #10 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mohsin Kaleem <mohkale <at> kisara.moe>
Cc: 71282 <at> debbugs.gnu.org
Subject: Re: bug#71282: 30.0.50; hl-line overlay priority has no affect
Date: Fri, 31 May 2024 08:44:23 +0300

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.

Previous Next

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