bug#64101: 29.0.91; Eglot inlay hints rendered out of order

[João Távora]

Stefan Monnier <monnier@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