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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Mohsin Kaleem <mohkale <at> kisara.moe>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71282 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#71282: 30.0.50; hl-line overlay priority has no affect
Date: Mon, 1 Jul 2024 14:50:59 +0100

On Mon, Jul 1, 2024 at 1:35 PM Mohsin Kaleem <mohkale <at> kisara.moe> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> 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

Previous Next

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