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

From: João Távora <[email-masked]>
Date: Mon, 1 Jul 2024 14:50:59 +0100

On Mon, Jul 1, 2024 at 1:35 PM Mohsin Kaleem <[email-masked]> wrote:
>
> Eli Zaretskii <[email-masked]> writes:
> >>
> >> Then if that mechanism doesn't require anything specific of package X or
> >> Y, it should be possible to condense in a function (that shouldn't live in
> >> Eglot, but OK it it starts life there, I guess) that takes a face with
> >> a number of
> >> attributes,merges with whatever is "the face of the buffer text" and return
> >> an (anonymous) face.  If so, then that "mistery" function is the fix
> >> to this issue.
> >
> > Patches welcome.
>
> Any tips or suggestions for where to start if one wants to implement
> something like this? I'll try taking a look at some of the related code
> and how to get some kind of merging setup. Probably not very soon tho
> XD.

Moshin, I don't know if you read my later email, but I'd like to point
out that that function, which I briefly thought could be used to fix this
issue, is NOT the solution.  I'm fairly sure it won't work, at least
not for the hl-line use case you bring forth.  As far as I can see,
short of an xdisp.c fix for this, the Elisp solution is very hard and
involves hl-line doing perhaps extraordinary amounts of work in
'hl-line-highlight' and 'hl-line-unhighlight' to account for intersecting
overlays, their after strings, before strings, but only in those
parts that touch the line to be highlighted.

João