GNU bug report logs - #64101
29.0.91; Eglot inlay hints rendered out of order

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Krzysztof Klimonda <kklimonda <at> syntaxhighlighted.com>, 64101 <at> debbugs.gnu.org
Subject: bug#64101: 29.0.91; Eglot inlay hints rendered out of order
Date: Sat, 17 Jun 2023 23:25:59 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Should the overlays created for the
>>> inlay hints be forced to be sorted in some particular order?
>> Maybe, and there is definitely an order they should be sorted.
>
> If they start and end at the exact same place, then the ordering by
> default is arbitrary (IIRC it's sorted by memory address, simply
> because we needed some cheap way to make the ordering total).

Understood.

>> --- a/lisp/progmodes/eglot.el
>> +++ b/lisp/progmodes/eglot.el
>> @@ -3755,8 +3755,9 @@ eglot--update-hints-1
>>                       (if peg-after-p
>>                           (make-overlay (point) (1+ (point)) nil t)
>>                         (make-overlay (1- (point)) (point) nil nil nil)))
>> -                   (do-it (label lpad rpad firstp)
>> -                     (let* ((tweak-cursor-p (and firstp peg-after-p))
>> +                   (do-it (label lpad rpad i)
>> +                     (let* ((firstp (zerop i))
>> +                            (tweak-cursor-p (and firstp peg-after-p))
>>                              (ov (make-ov))
>>                              (text (concat lpad label rpad)))
>>                         (when tweak-cursor-p (put-text-property 0 1 'cursor 1 text))
>> @@ -3767,17 +3768,18 @@ eglot--update-hints-1
>>                                               (1 'eglot-type-hint-face)
>>                                               (2 'eglot-parameter-hint-face)
>>                                               (_ 'eglot-inlay-hint-face))))
>> +                       (overlay-put ov 'priority i)
>>                         (overlay-put ov 'eglot--inlay-hint t)
>>                         (overlay-put ov 'evaporate t)
>>                         (overlay-put ov 'eglot--overlay t))))
>
> The `priority` property is a source of problem in itself

How so?  What problem are you talking about.

> so I'd recommend to use its weaker version where the value is a cons
> cell `(nil . SECONDARY)`.  This way the SECONDARY priority will only
> be used as a last recourse (before using pointer addresses).

This would make some sense, but I'm not sure I'm doing it correctly.  If
I replace the above line with

   (overlay-put ov 'priority `(nil . i))

Everything still works ... on my Linux builds.  But then so does

   (overlay-put ov 'priority `(nil . (- 100 i)))

Which I certainly _didn't_ expect to work!  For sanity, I can verify
that:

   (overlay-put ov 'priority `(- 100 i))

really does give me the inverse ordering, so at least I know that
PRIMARY priorities are working.

João

Previous Next

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