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

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

[Mohsin Kaleem]

Hi there,

Looks like there's no way to give hl-line a higher priority than other
text overlays. 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. 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.

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-05-08 built on mk-desktop
Repository revision: 840c33070dc789d5095a47fa65f4f77564cd6e59
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-m17n-flt --without-gconf
 --with-native-compilation=yes --with-xinput2 --with-x-toolkit=gtk3
 --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
 -mno-omit-leaf-frame-pointer -g
 -ffile-prefix-map=/home/mohkale/.cache/yay/emacs-git/src=/usr/src/debug/emacs-git
 -flto=auto' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed
 -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_MESSAGES: C
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  hl-line-mode: t
  straight-use-package-mode: t
  straight-package-neutering-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils hl-line compile
text-property-search comint ansi-osc ansi-color ring comp-run
comp-common rx straight-autoloads cl-seq cl-extra help-mode straight
cl-macs cl-loaddefs cl-lib +core-setup-paths xdg subr-x term/st
term/xterm xterm byte-opt gv bytecomp byte-compile rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)

Memory information:
((conses 16 135391 97166) (symbols 48 12063 45)
 (strings 32 37667 9732) (string-bytes 1 2453600) (vectors 16 17732)
 (vector-slots 8 966098 204470) (floats 8 37 12)
 (intervals 56 463 162) (buffers 992 13))

-- 
Mohsin Kaleem

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

[Eli Zaretskii]

tags 71282 notabug
thanks

> From: Mohsin Kaleem <mohkale@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.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

[Mohsin Kaleem]

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?

-- 
Mohsin Kaleem

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

[Eli Zaretskii]

> 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.

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

[Mohsin Kaleem]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

This seems at least to me like a problem not specific to eglot. Any
package trying to support overlay annotations in buffer will have the
same problem. This is either a limitation of hl-line and it should have
bespoke logic to override overlay faces or the overlay mechanism itself
should be flexible enough to respect this (with the priority suggestion
from before). Although probably makes sense to wait and see what João
says :-).

-- 
Mohsin Kaleem

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

[Eli Zaretskii]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Cc: stefankangas@gmail.com, 71282@debbugs.gnu.org
> Date: Sun, 30 Jun 2024 14:41:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> This seems at least to me like a problem not specific to eglot. Any
> package trying to support overlay annotations in buffer will have the
> same problem.

I don't think it's a "problem".  Overlay strings have their own faces,
and those override the faces of buffer text.

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

[João Távora]

On Sun, Jun 30, 2024 at 3:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Mohsin Kaleem <mohkale@kisara.moe>
> > Cc: stefankangas@gmail.com, 71282@debbugs.gnu.org
> > Date: Sun, 30 Jun 2024 14:41:13 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:

> I don't think it's a "problem".  Overlay strings have their own faces,
> and those override the faces of buffer text.

If I understand the scenario correctly, I agree with Moshin that this
is a more general issue.  There should be some way for overlays
used by a package X to easily combine with an existing an
existing background color, even if that background color is mandated
by some hl-current-line extension Y.  This mechanism shouldn't rely
on making X aware of Y.  Maybe if the implementation of Y were
moved to C display core, like display-line-numbers-mode.  Or maybe
not, I haven't looked into it (and I don't plan to, sorry).

João

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

[Mohsin Kaleem]

João Távora <joaotavora@gmail.com> writes:

> This mechanism shouldn't rely on making X aware of Y. Maybe if the
> implementation of Y were moved to C display core, like
> display-line-numbers-mode. Or maybe not, I haven't looked into it (and
> I don't plan to, sorry).

Thanks João.

Going to back to the original discussion is there a reason
before-strings in overlays don't respect priorities? I realise it's
documented but I'm more curious about the why than the what? Was there a
use case for these properties in overlays to not be overridable (which
from what I understand is the reason for this conflict between hl-line and
overlay annotations is happening).

-- 
Mohsin Kaleem

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

[Eli Zaretskii]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Cc: stefankangas@gmail.com, 71282@debbugs.gnu.org
> Date: Sun, 30 Jun 2024 16:21:05 +0100
> 
> Going to back to the original discussion is there a reason
> before-strings in overlays don't respect priorities? I realise it's
> documented but I'm more curious about the why than the what? Was there a
> use case for these properties in overlays to not be overridable (which
> from what I understand is the reason for this conflict between hl-line and
> overlay annotations is happening).

I thought I explained that: priorities are a way of determining which
overlay "wins" when several overlays affect the same text and provide
different values for the same properties.  But in this case, each
overlay affects different text, so there's no need to consider
priorities, and therefore Emacs doesn't.

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 30 Jun 2024 16:12:55 +0100
> Cc: Mohsin Kaleem <mohkale@kisara.moe>, stefankangas@gmail.com, 71282@debbugs.gnu.org
> 
> On Sun, Jun 30, 2024 at 3:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Mohsin Kaleem <mohkale@kisara.moe>
> > > Cc: stefankangas@gmail.com, 71282@debbugs.gnu.org
> > > Date: Sun, 30 Jun 2024 14:41:13 +0100
> > >
> > > Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think it's a "problem".  Overlay strings have their own faces,
> > and those override the faces of buffer text.
> 
> If I understand the scenario correctly, I agree with Moshin that this
> is a more general issue.  There should be some way for overlays
> used by a package X to easily combine with an existing an
> existing background color, even if that background color is mandated
> by some hl-current-line extension Y.  This mechanism shouldn't rely
> on making X aware of Y.

The mechanism exists: find the face of the buffer text, and use it (or
some of its attributes, like background color) in determining the face
of the overlay string.

In some cases, Emacs does this merging automatically, but this is not
one of those cases.  (I think in this case if hl-line uses text
properties instead of overlays, this will happen automatically.  But I
didn't try that, and I might be missing something in this complex
issue.)

> Maybe if the implementation of Y were moved to C display core, like
> display-line-numbers-mode.  Or maybe not, I haven't looked into it
> (and I don't plan to, sorry).

That's unrelated.  The order of merging face information is documented
in the ELisp manual, and changing it is out of the question, because
it worked like that for many years, and any change in it is bound to
break something out there.

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

[João Távora]

On Sun, Jun 30, 2024 at 4:34 PM Eli Zaretskii <eliz@gnu.org> wrote:

> The mechanism exists: find the face of the buffer text, and use it (or
> some of its attributes, like background color) in determining the face
> of the overlay string.

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.

                        (overlay-put ov (if peg-after-p 'before-string
'after-string)
                                     (propertize
                                      text
-                                     'face (pcase kind
-                                             (1 'eglot-type-hint-face)
-                                             (2 'eglot-parameter-hint-face)
-                                             (_ 'eglot-inlay-hint-face))))
+                                     'face
+                                     (mistery (pcase kind
+                                                (1 'eglot-type-hint-face)
+                                                (2 'eglot-parameter-hint-face)
+                                                (_ 'eglot-inlay-hint-face)))))


Else, your earlier suggestion proposing "Eglot to be sensitive
to hl-line" -- which I understood as creating an explicit dependency
between Eglot and hl-line -- is not a good one, and this is where I
agree with Moshin.

João

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

[João Távora]

On Sun, Jun 30, 2024 at 4:50 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Sun, Jun 30, 2024 at 4:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > The mechanism exists: find the face of the buffer text, and use it (or
> > some of its attributes, like background color) in determining the face
> > of the overlay string.
>
> 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.
>
>                         (overlay-put ov (if peg-after-p 'before-string
> 'after-string)
>                                      (propertize
>                                       text
> -                                     'face (pcase kind
> -                                             (1 'eglot-type-hint-face)
> -                                             (2 'eglot-parameter-hint-face)
> -                                             (_ 'eglot-inlay-hint-face))))
> +                                     'face
> +                                     (mistery (pcase kind
> +                                                (1 'eglot-type-hint-face)
> +                                                (2 'eglot-parameter-hint-face)
> +                                                (_ 'eglot-inlay-hint-face)))))

Never mind, this won't work as whatever face is determined
at any given moment, will cease to be adequate as soon as the
hl-line extension chooses another face for those positions.
So if no low-level automatic merging of overlay faces is to
happen in the display engine, this problem doesn't have a solution.
Or maybe hl-line could forcibly and constantly repropertize all the
overlays on a given line with a given background color if that
attribute isn't explicit in the overlay's faces (main text, before string
or after string).  Then restore those things it as soon as the line is
released.  If this idea is not too complicated, too brittle or too
inneficient, it is at any rate not something that concerns Eglot.

João

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 30 Jun 2024 16:50:32 +0100
> Cc: mohkale@kisara.moe, stefankangas@gmail.com, 71282@debbugs.gnu.org
> 
> On Sun, Jun 30, 2024 at 4:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The mechanism exists: find the face of the buffer text, and use it (or
> > some of its attributes, like background color) in determining the face
> > of the overlay string.
> 
> 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.

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

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Sun, Jun 30, 2024, 18:37 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Sun, 30 Jun 2024 16:50:32 +0100
> > Cc: mohkale@kisara.moe, stefankangas@gmail.com, 71282@debbugs.gnu.org
> >
> > On Sun, Jun 30, 2024 at 4:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > The mechanism exists: find the face of the buffer text, and use it (or
> > > some of its attributes, like background color) in determining the face
> > > of the overlay string.
> >
> > 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.
>

No need, not for this at last. I've already explained how it doesn't fix
the problem, but anyone is free to experiment.

>

[-- Attachment #2: Type: text/html, Size: 2038 bytes --]

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

[Mohsin Kaleem]

Eli Zaretskii <eliz@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.

In the meantime could this issue ticket be re-opened? I think it was
closed as resolved but I think it's still a problem with the way
annotations are setup in Emacs.

-- 
Mohsin Kaleem

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

[João Távora]

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

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

[Mohsin Kaleem]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think it's a "problem".  Overlay strings have their own faces,
> and those override the faces of buffer text.

Yes, but hl-line is meant to overlay all of that no? It's supposed to a
give consistent highlighted background to the contents of the current
line. Which as of now does not work with annotations implemented as
overlays.

-- 
Mohsin Kaleem

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

[Eli Zaretskii]

> From: Mohsin Kaleem <mohkale@kisara.moe>
> Cc: joaotavora@gmail.com, stefankangas@gmail.com, 71282@debbugs.gnu.org
> Date: Sun, 30 Jun 2024 16:18:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think it's a "problem".  Overlay strings have their own faces,
> > and those override the faces of buffer text.
> 
> Yes, but hl-line is meant to overlay all of that no?

Maybe that's what hl-line wants to do (and I'm not sure even that is
correct), but doing that is impossible in Emacs, not with a single
overlay on the line's text.  Emacs simply doesn't support that, never
did.