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

[Eli Zaretskii <eliz@gnu.org>]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Cc: 71282-done@debbugs.gnu.org
> Date: Sun, 30 Jun 2024 12:42:41 +0100
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> >> 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.
> 
> Hi, sorry, I forgot I opened this. If it's expected behaviour is the
> usage of overlays here by eglot and related packages wrong? Even if it's
> expected this is the only editor I've used which has inlay hints that
> override attributes like hl-line. Is there an alternative way for eglot
> to support inlay hints that isn't in conflict with hl-line?

The only way I can think of is for Eglot to be sensitive to hl-line
and to set up the colors of the inlay hints to be consistent with the
hl-line's background.  Not sure if João (CC'ed) will like this.

FWIW, I see no problem in the current behavior, but then I'm not an
hl-line user.