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

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

[Krzysztof Klimonda]

When using eglot with rust-analyzer some inlay hints are not rendered
correctly. For example, in the following code snippet, inlay hint for
the `let vec =` is rendered as such:

> >>>Vec<Arc<Mutex<Item: 

and not

> : <Vec<Arc<Mutex<Item>>>

It works fine for simple hints (like `let x` in my example).

Looking at what's happening, it seems eglot is creating separate
overlays for each element of the returned `InlayHintLabelPart` with
the same beginning in the buffer. From poking around I've noticed
that overlays have been rewritten recently, and the order of overlays
for the given position no longer seems to be fixed.

Code example below:
---8<---8<---8<---
use std::sync::{Arc, Mutex};

mod static_uninit;

struct Item;

fn test() {
    let vec = vec![Arc::new(Mutex::new(Item))];
    let x = 1;
}
---8<---8<---8<---




In GNU Emacs 29.0.91 (build 1, x86_64-apple-darwin22.3.0, NS
appkit-2299.40 Version 13.2.1 (Build 22D68)) of 2023-06-11 built on
sapphire.local
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.2.1

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs-plus@29/29.0.90/share/info/emacs
--prefix=/usr/local/Cellar/emacs-plus@29/29.0.90 --with-xml2
--with-gnutls --with-native-compilation --without-compress-install
--without-dbus --without-imagemagick --with-modules --with-rsvg
--with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
-march=nehalem -mmacosx-version-min=13
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
'CPPFLAGS=-I/usr/local/opt/zlib/include -I/usr/local/opt/jpeg/include
-I/usr/local/opt/icu4c/include -I/usr/local/opt/openssl@1.1/include
-F/usr/local/Frameworks
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk'
'LDFLAGS=-L/usr/local/opt/zlib/lib -L/usr/local/opt/jpeg/lib
-L/usr/local/opt/icu4c/lib -L/usr/local/opt/openssl@1.1/lib
-L/usr/local/lib -F/usr/local/Frameworks
-Wl,-headerpad_max_install_names
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
-L/usr/local/opt/libgccjit/lib''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Rust

Minor modes in effect:
  shell-dirtrack-mode: t
  eglot-inlay-hints-mode: t
  eglot--managed-mode: t
  flymake-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-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 epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils misearch multi-isearch pulse color rust-ts-mode
c-ts-common treesit etags fileloop generator time-date shell pcomplete
eglot external-completion array filenotify jsonrpc ert pp ewoc debug
backtrace find-func xref flymake-proc flymake thingatpt compile
text-property-search comint ansi-osc ansi-color ring pcase url-util
url-parse auth-source eieio eieio-core password-cache json map url-vars
project byte-opt imenu vc-git diff-mode easy-mmode vc-dispatcher
cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv
cl-extra help-mode bytecomp byte-compile cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win 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 kqueue cocoa ns lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 161413 14006)
(symbols 48 12244 0)
(strings 32 41810 3481)
(string-bytes 1 1383853)
(vectors 16 31896)
(vector-slots 8 582797 14839)
(floats 8 140 71)
(intervals 56 375 0)
(buffers 984 22))

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

[Eli Zaretskii]

> From: Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>
> Date: Thu, 15 Jun 2023 23:23:45 +0200
> 
> 
> When using eglot with rust-analyzer some inlay hints are not rendered
> correctly. For example, in the following code snippet, inlay hint for
> the `let vec =` is rendered as such:
> 
> > >>>Vec<Arc<Mutex<Item: 
> 
> and not
> 
> > : <Vec<Arc<Mutex<Item>>>
> 
> It works fine for simple hints (like `let x` in my example).
> 
> Looking at what's happening, it seems eglot is creating separate
> overlays for each element of the returned `InlayHintLabelPart` with
> the same beginning in the buffer. From poking around I've noticed
> that overlays have been rewritten recently, and the order of overlays
> for the given position no longer seems to be fixed.
> 
> Code example below:
> ---8<---8<---8<---
> use std::sync::{Arc, Mutex};
> 
> mod static_uninit;
> 
> struct Item;
> 
> fn test() {
>     let vec = vec![Arc::new(Mutex::new(Item))];
>     let x = 1;
> }
> ---8<---8<---8<---

João, are you looking into this?  Should the overlays created for the
inlay hints be forced to be sorted in some particular order?

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

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

> João, are you looking into this?  

I looked at a very similar issue: https://github.com/joaotavora/eglot/discussions/1239

There, Milan Jovanovic , reports something very similar,
if not completely identical, for Emacs 29.  I asked
Milan to send mail here.  Maybe Krzystof and Milan are
related, or this is just a coincidence?

Anyway, I tried to reproduce the problem on both Emacs 29
and 30 and couldn't.

The problem also doesn't happen on Emacs 28.  So I don't know what is up
and the "recent overlay rewrite" (when?) doesn't seem to have an effect.
I don't have a Mac OS machine to test.

> 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.
But as far as I can personally observe, there is no problem yet,
so it would be best to first understand the problem.

But maybe Milan/Krzystof can try this patch:

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index a65795f1dfc..0c000f72ec7 100644
--- 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))))
-                (if (stringp label) (do-it label left-pad right-pad t)
+                (if (stringp label) (do-it label left-pad right-pad 0)
                   (cl-loop
                    for i from 0 for ldetail across label
                    do (eglot--dbind ((InlayHintLabelPart) value) ldetail
                         (do-it value
                                (and (zerop i) left-pad)
                                (and (= i (1- (length label))) right-pad)
-                               (zerop i))))))))))
+                               i)))))))))
     (jsonrpc-async-request
      (eglot--current-server-or-lose)
      :textDocument/inlayHint

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
>   64101@debbugs.gnu.org
> Date: Sat, 17 Jun 2023 10:39:32 +0100
> 
> Anyway, I tried to reproduce the problem on both Emacs 29
> and 30 and couldn't.
> 
> The problem also doesn't happen on Emacs 28.  So I don't know what is up
> and the "recent overlay rewrite" (when?) doesn't seem to have an effect.
> I don't have a Mac OS machine to test.

Emacs 29 comes with a completely different implementation of overlays
than previous versions.

I don't think this is specific to macOS, but perhaps the order in
which overlays are arranged is arbitrary to some extent, in which case
different systems can have different orders.

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

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
>>   64101@debbugs.gnu.org
>> Date: Sat, 17 Jun 2023 10:39:32 +0100
>> 
>> Anyway, I tried to reproduce the problem on both Emacs 29
>> and 30 and couldn't.
>> 
>> The problem also doesn't happen on Emacs 28.  So I don't know what is up
>> and the "recent overlay rewrite" (when?) doesn't seem to have an effect.
>> I don't have a Mac OS machine to test.
>
> Emacs 29 comes with a completely different implementation of overlays
> than previous versions.
>
> I don't think this is specific to macOS, but perhaps the order in
> which overlays are arranged is arbitrary to some extent, in which case
> different systems can have different orders.

I would find this "undefined order" strange, and perhaps a bug in
itself.  Maybe whoever rewrote the overlay code (Stefan?) could chime
in.

In any case, one defensive option is to push the patch I showed to Emacs
29.  Subject, of course, to testing on at least some machine where the
problem does indeed happen.

João

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

[Krzysztof Klimonda]

Hi Joao,

The attached patch has indeed fixed the issue.

Additionally, I've tested the behaviour on emacs 28.2 and the bug persists, so it seems to be unrelated to any overlay changes.

On Sat, Jun 17, 2023, at 11:39, João Távora wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> João, are you looking into this?  
>
> I looked at a very similar issue: 
> https://github.com/joaotavora/eglot/discussions/1239
>
> There, Milan Jovanovic , reports something very similar,
> if not completely identical, for Emacs 29.  I asked
> Milan to send mail here.  Maybe Krzystof and Milan are
> related, or this is just a coincidence?
>
> Anyway, I tried to reproduce the problem on both Emacs 29
> and 30 and couldn't.
>
> The problem also doesn't happen on Emacs 28.  So I don't know what is up
> and the "recent overlay rewrite" (when?) doesn't seem to have an effect.
> I don't have a Mac OS machine to test.
>
>> 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.
> But as far as I can personally observe, there is no problem yet,
> so it would be best to first understand the problem.
>
> But maybe Milan/Krzystof can try this patch:
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index a65795f1dfc..0c000f72ec7 100644
> --- 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))))
> -                (if (stringp label) (do-it label left-pad right-pad t)
> +                (if (stringp label) (do-it label left-pad right-pad 0)
>                    (cl-loop
>                     for i from 0 for ldetail across label
>                     do (eglot--dbind ((InlayHintLabelPart) value) 
> ldetail
>                          (do-it value
>                                 (and (zerop i) left-pad)
>                                 (and (= i (1- (length label))) 
> right-pad)
> -                               (zerop i))))))))))
> +                               i)))))))))
>      (jsonrpc-async-request
>       (eglot--current-server-or-lose)
>       :textDocument/inlayHint

-- 
  Krzysztof Klimonda
  kklimonda@syntaxhighlighted.com

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: kklimonda@syntaxhighlighted.com,  64101@debbugs.gnu.org,
>  monnier@iro.umontreal.ca
> Date: Sat, 17 Jun 2023 13:19:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emacs 29 comes with a completely different implementation of overlays
> > than previous versions.
> >
> > I don't think this is specific to macOS, but perhaps the order in
> > which overlays are arranged is arbitrary to some extent, in which case
> > different systems can have different orders.
> 
> I would find this "undefined order" strange, and perhaps a bug in
> itself.  Maybe whoever rewrote the overlay code (Stefan?) could chime
> in.

It wasn't Stefan, he just merged the branch to master and fixed bugs.

But why do you say this is a bug?  Does any documentation promise any
particular order of overlays?

> In any case, one defensive option is to push the patch I showed to Emacs
> 29.  Subject, of course, to testing on at least some machine where the
> problem does indeed happen.

Yes, let's wait for the confirmation that it fixes the problem.

Thanks.

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

[João Távora]

On Sat, Jun 17, 2023 at 2:17 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > I would find this "undefined order" strange, and perhaps a bug in
> > itself.  Maybe whoever rewrote the overlay code (Stefan?) could chime
> > in.
>
> It wasn't Stefan, he just merged the branch to master and fixed bugs.
>
> But why do you say this is a bug?

I didn't: I suggested it _might_ be and asked for an expert opinion
to weigh in.  It's quite different.

> Does any documentation promise any particular order of overlays?

No, not that I know of, but it's just the behaviour I've always observed.
This seemingly MacOS-specific undefinition is the first time I hear of this
behaviour.

IMO, unexpected behaviour doesn't have to go against actual documented
behaviour to be considered a bug.  However if you know that this
indefinition exists and you want it to enshrine it (say, for some performance
reason) then I believe this should be documented.

> > In any case, one defensive option is to push the patch I showed to Emacs
> > 29.  Subject, of course, to testing on at least some machine where the
> > problem does indeed happen.
>
> Yes, let's wait for the confirmation that it fixes the problem.

I think it has already been tested successfully.

João

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 17 Jun 2023 14:26:48 +0100
> Cc: kklimonda@syntaxhighlighted.com, 64101@debbugs.gnu.org, 
> 	monnier@iro.umontreal.ca
> 
> > Does any documentation promise any particular order of overlays?
> 
> No, not that I know of, but it's just the behaviour I've always observed.
> This seemingly MacOS-specific undefinition is the first time I hear of this
> behaviour.
> 
> IMO, unexpected behaviour doesn't have to go against actual documented
> behaviour to be considered a bug.  However if you know that this
> indefinition exists and you want it to enshrine it (say, for some performance
> reason) then I believe this should be documented.

What order did your code expect in that case?

> > > In any case, one defensive option is to push the patch I showed to Emacs
> > > 29.  Subject, of course, to testing on at least some machine where the
> > > problem does indeed happen.
> >
> > Yes, let's wait for the confirmation that it fixes the problem.
> 
> I think it has already been tested successfully.

Yes, so I think the fix should be installed.

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

[João Távora]

On Sat, Jun 17, 2023 at 3:12 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > IMO, unexpected behaviour doesn't have to go against actual documented
> > behaviour to be considered a bug.  However if you know that this
> > indefinition exists and you want it to enshrine it (say, for some performance
> > reason) then I believe this should be documented.
>
> What order did your code expect in that case?

The current order that I see on all my GNU Linux builds of Emacs (and also
my Windows builds, I'm fairly certain).  The after-string and before-string
of a a more recently created overlay is displayed after the least
recently created overlay, all other overlay things being equal,
of course.

> > > > In any case, one defensive option is to push the patch I showed to Emacs
> > > > 29.  Subject, of course, to testing on at least some machine where the
> > > > problem does indeed happen.
> > >
> > > Yes, let's wait for the confirmation that it fixes the problem.
> >
> > I think it has already been tested successfully.
>
> Yes, so I think the fix should be installed.

Done.

João

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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 17 Jun 2023 15:29:38 +0100
> Cc: kklimonda@syntaxhighlighted.com, 64101@debbugs.gnu.org, 
> 	monnier@iro.umontreal.ca
> 
> > What order did your code expect in that case?
> 
> The current order that I see on all my GNU Linux builds of Emacs (and also
> my Windows builds, I'm fairly certain).  The after-string and before-string
> of a a more recently created overlay is displayed after the least
> recently created overlay, all other overlay things being equal,
> of course.

That was never the case.  The creation order has no direct relevance
to the display order of overlays that cover the same text and have the
same priority.  What can affect the order is the address of each
overlay in memory, but I don't think you can rely on memory-allocation
routines to always allocate memory in the increasing order of
addresses.

So I don't think the code should rely on this assumption.

Stefan, am I missing something?

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

[João Távora]

On Sat, Jun 17, 2023 at 4:50 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 17 Jun 2023 15:29:38 +0100
> > Cc: kklimonda@syntaxhighlighted.com, 64101@debbugs.gnu.org,
> >       monnier@iro.umontreal.ca
> >
> > > What order did your code expect in that case?
> >
> > The current order that I see on all my GNU Linux builds of Emacs (and also
> > my Windows builds, I'm fairly certain).  The after-string and before-string
> > of a a more recently created overlay is displayed after the least
> > recently created overlay, all other overlay things being equal,
> > of course.
>
> That was never the case. The creation order has no direct relevance
> to the display order of overlays that cover the same text and have the
> same priority.  What can affect the order is the address of each
> overlay in memory, but I don't think you can rely on memory-allocation
> routines to always allocate memory in the increasing order of
> addresses.

It's not true that it "was never the case".  Experimentally, it _is_
the case on all the Linux and (and Windows) builds I've ever used
to test Eglot on.  So instead of "never", I would say "most often,
though not necessarily always" and document this, else people like
me may assume that the behaviour they observe is guaranteed by the
system.

> So I don't think the code should rely on this assumption.

That's perfectly fair.  AFAICT, it doesn't anymore.

João

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

If you need a particular ordering between such overlays, then you
definitely need to use the `priority` property.

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

The doc discourages this use because when I introduced it (for use by
the Lisp reimplementation of the region highlighting, some time around
Emacs-24) I wasn't too sure how it would play out.  But I suspect we
should change the doc to let people use it without a bad conscience (or
maybe even encourage its use).


        Stefan

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

[Milan Jovanovic]

Hi,
This fixes more complicated types that I had issue with but I’ve noticed that it now breaks this example:
let mut x = vec![1,2,3];
x.insert(1, 1) 
with type hints inserted => x.insert(: index0, : element1)

> But maybe Milan/Krzystof can try this patch:
>
> diff —git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index a65795f1dfc..0c000f72ec7 100644
> --- 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))))
> -                (if (stringp label) (do-it label left-pad right-pad t)
> +                (if (stringp label) (do-it label left-pad right-pad 0)
>                   (cl-loop
>                    for i from 0 for ldetail across label
>                    do (eglot--dbind ((InlayHintLabelPart) value) ldetail
>                         (do-it value
>                                (and (zerop i) left-pad)
>                                (and (= i (1- (length label))) right-pad)
> -                               (zerop i))))))))))
> +                               i)))))))))
>     (jsonrpc-async-request
>      (eglot--current-server-or-lose)
>      :textDocument/inlayHint

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

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

[João Távora]

On Sat, Jun 17, 2023 at 9:55 PM Milan Jovanovic <milanj@gmail.com> wrote:

> Hi,
> This fixes more complicated types that I had issue with but I’ve noticed that it now breaks this example:
> let mut x = vec![1,2,3];
> x.insert(1, 1)
> with type hints inserted => x.insert(: index0, : element1)

I can't reproduce this either.  In fact, in this case there are no
coinciding overlays so I can't understand how this might have affected
anything.

To be clear, I don't have the Mac OS hardware triggers this problem
(or the specific memory allocation libraries presumed to be the source
 of the different behaviour).  This makes fixing the problem quite hard.

Also, Milan, please next time it's fine to CC everybody in the thread
("reply to all").  Or at least just me, as it helps my workflow.

Finally please try to provide complete error reproduction recipes starting
from Emacs -Q so that there is a low chance of of interference from external
factors like your configuration and a higher chance that others try to
investigate this problem.

João

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> The `priority` property is a source of problem in itself
> How so?  What problem are you talking about.

Most overlays don't have a `priority` property, so any overlay with
a `priority` property set to a number greater than 0 will have priority
over basically everything else, which is rarely what you want.

Often, the resulting problems take a while to appear and when they do,
it's in relation with some other package elsewhere, so that package's
authors end up working around the problem by adding another `priority`
property on their overlays, thus spreading the problem further.

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

Did you forget the comma?

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


-- Stefan

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

[João Távora]

On Sun, Jun 18, 2023 at 1:45 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > 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))
>
> Did you forget the comma?
>
>     (overlay-put ov 'priority `(nil . ,i))

Hehe, no, not in real life, only in the examples in my email, which
are all messed up.  Let me try again...

Yep, SECONDARY doesn't seem to do anything

<no form>   => correctly sorted overlays
(overlay-put ov 'priority i)  => correctly sorted overlays
(overlay-put ov 'priority (- 10 i) => reverse sorted overlays
(overlay-put ov 'priority `(nil . ,i)  => correctly sorted overlays
(overlay-put ov 'priority `(nil . ,(- 10 i)  => correctly sorted overlays (!)

Also confirmed with M-x describe text properties that the priority
property values are sane and look like (nil . 3).

João

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > 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))
>>
>> Did you forget the comma?
>>
>>     (overlay-put ov 'priority `(nil . ,i))
>
> Hehe, no, not in real life, only in the examples in my email, which
> are all messed up.  Let me try again...
>
> Yep, SECONDARY doesn't seem to do anything
>
> <no form>   => correctly sorted overlays
> (overlay-put ov 'priority i)  => correctly sorted overlays
> (overlay-put ov 'priority (- 10 i) => reverse sorted overlays
> (overlay-put ov 'priority `(nil . ,i)  => correctly sorted overlays
> (overlay-put ov 'priority `(nil . ,(- 10 i)  => correctly sorted overlays (!)

Hmm... do you have a simple recipe that I could try?
Do those overlays all really share the same start and end?
IOW, can you check/show

    (mapcar (lambda (ol)
              `(,(overlay-start ol)
                ,(overlay-end ol)
                . ,(overlay-get ol 'priority)))
            (overlays-at <POS> t))

?


        Stefan

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

[João Távora]

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

>>> The `priority` property is a source of problem in itself
>> How so?  What problem are you talking about.
>
> Most overlays don't have a `priority` property, so any overlay with
> a `priority` property set to a number greater than 0 will have priority
> over basically everything else, which is rarely what you want.
>
> Often, the resulting problems take a while to appear and when they do,
> it's in relation with some other package elsewhere, so that package's
> authors end up working around the problem by adding another `priority`
> property on their overlays, thus spreading the problem further.

Right, that makes sense.  It's more or less what I feared too, though
this is all speculative at this point.  Anyway, can you explain this?
Take this scratch buffer

   ;; This buffer is for text that is not saved, and for Lisp evaluation.
   ;; To create a file, visit it with C-x C-f and enter text in its buffer.
    
   (progn
     (mapc #'delete-overlay (overlays-in (point-min) (point-max)))
     (let ((a (make-overlay 10 20))
           (b (make-overlay 10 20)))
       (overlay-put a 'after-string (propertize "aaaa" 'face 'highlight))
       (overlay-put b 'after-string (propertize "bbbb" 'face 'speedbar-highlight-face))
       ;; (overlay-put a 'priority 1)
       ;; (overlay-put b 'priority 2)
       (overlay-put a 'priority `(nil . 1))
       (overlay-put b 'priority `(nil . 2))
       ))

This displays AAAABBBB eventually, but I would expect it to show
BBBBAAAA, which is what I get if I use "primary" priorities.

João
 

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Right, that makes sense.  It's more or less what I feared too, though
> this is all speculative at this point.  Anyway, can you explain this?

Nope :-(

> Take this scratch buffer
>
>    ;; This buffer is for text that is not saved, and for Lisp evaluation.
>    ;; To create a file, visit it with C-x C-f and enter text in its buffer.
>     
>    (progn
>      (mapc #'delete-overlay (overlays-in (point-min) (point-max)))
>      (let ((a (make-overlay 10 20))
>            (b (make-overlay 10 20)))
>        (overlay-put a 'after-string (propertize "aaaa" 'face 'highlight))
>        (overlay-put b 'after-string (propertize "bbbb" 'face 'speedbar-highlight-face))
>        ;; (overlay-put a 'priority 1)
>        ;; (overlay-put b 'priority 2)
>        (overlay-put a 'priority `(nil . 1))
>        (overlay-put b 'priority `(nil . 2))
>        ))
>
> This displays AAAABBBB eventually, but I would expect it to show
> BBBBAAAA, which is what I get if I use "primary" priorities.

I can indeed reproduce the different rendering here, yet the sorting
done by `overlays-at` is the same in both cases, so it looks like we
sort some other way somewhere (presumably somewhere in the C code).


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>    ;; This buffer is for text that is not saved, and for Lisp evaluation.
>    ;; To create a file, visit it with C-x C-f and enter text in its buffer.
>     
>    (progn
>      (mapc #'delete-overlay (overlays-in (point-min) (point-max)))
>      (let ((a (make-overlay 10 20))
>            (b (make-overlay 10 20)))
>        (overlay-put a 'after-string (propertize "aaaa" 'face 'highlight))
>        (overlay-put b 'after-string (propertize "bbbb" 'face 'speedbar-highlight-face))
>        ;; (overlay-put a 'priority 1)
>        ;; (overlay-put b 'priority 2)
>        (overlay-put a 'priority `(nil . 1))
>        (overlay-put b 'priority `(nil . 2))
>        ))
>
> This displays AAAABBBB eventually, but I would expect it to show
> BBBBAAAA, which is what I get if I use "primary" priorities.

Hmm... I see that the (PRIMARY . SECONDARY) priority format is only
understood by `make_sortvec_item`, but not by
xdisp.c:RECORD_OVERLAY_STRING nor by buffer.c:record_overlay_string.

> Anyway, can you explain this?

[ Revised answer: ]  Yes.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Anyway, can you explain this?
> [ Revised answer: ]  Yes.

The patch below won't fix it, but maybe it can help someone else write
an actual fix?  AFAICT the place that needs fixing is the one in xdisp.c


        Stefan


diff --git a/src/buffer.c b/src/buffer.c
index 0c46b201586..26938dc5f78 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -3376,6 +3376,10 @@ record_overlay_string (struct sortstrlist *ssl, Lisp_Object str,
    that string via PSTR, if that variable is non-NULL.  The storage of
    the concatenated strings may be overwritten by subsequent calls.  */
 
+/* AFAICT, this is used only by indent.c:compute_motion,
+   which does not actually care about the ordering of the strings
+   but only its total width.  */
+
 ptrdiff_t
 overlay_strings (ptrdiff_t pos, struct window *w, unsigned char **pstr)
 {
@@ -3416,6 +3420,7 @@ overlay_strings (ptrdiff_t pos, struct window *w, unsigned char **pstr)
 			       endpos - startpos);
     }
 
+  /* FIXME: Use `sort_overlays` instead?  */
   if (overlay_tails.used > 1)
     qsort (overlay_tails.buf, overlay_tails.used, sizeof (struct sortstr),
 	   cmp_for_strings);
diff --git a/src/xdisp.c b/src/xdisp.c
index 8bcf2acfe04..f487dfbb5ba 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -6794,6 +6794,7 @@ #define RECORD_OVERLAY_STRING(OVERLAY, STRING, AFTER_P)			\
 
   /* Sort entries.  */
   if (n > 1)
+    /* FIXME: Use `sort_overlays` instead?  */
     qsort (entries, n, sizeof *entries, compare_overlay_entries);
 
   /* Record number of overlay strings, and where we computed it.  */

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

[Milan Jovanovic]

João,  is there a reason why (in Eglot) hint parts can’t be merged and only one overlay created ?
I fix it to create one overlay and I haven’t noticed any issues (I use it only with the rust-analyzer though).
Don’t know if this is stupid question,  don’t know much about LSP protocol (or Emacs internals).

Milan

> On 18. 6. 2023., at 16:22, João Távora <joaotavora@gmail.com> wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>>> The `priority` property is a source of problem in itself
>>> How so?  What problem are you talking about.
>> 
>> Most overlays don't have a `priority` property, so any overlay with
>> a `priority` property set to a number greater than 0 will have priority
>> over basically everything else, which is rarely what you want.
>> 
>> Often, the resulting problems take a while to appear and when they do,
>> it's in relation with some other package elsewhere, so that package's
>> authors end up working around the problem by adding another `priority`
>> property on their overlays, thus spreading the problem further.
> 
> Right, that makes sense.  It's more or less what I feared too, though
> this is all speculative at this point.  Anyway, can you explain this?
> Take this scratch buffer
> 
>   ;; This buffer is for text that is not saved, and for Lisp evaluation.
>   ;; To create a file, visit it with C-x C-f and enter text in its buffer.
> 
>   (progn
>     (mapc #'delete-overlay (overlays-in (point-min) (point-max)))
>     (let ((a (make-overlay 10 20))
>           (b (make-overlay 10 20)))
>       (overlay-put a 'after-string (propertize "aaaa" 'face 'highlight))
>       (overlay-put b 'after-string (propertize "bbbb" 'face 'speedbar-highlight-face))
>       ;; (overlay-put a 'priority 1)
>       ;; (overlay-put b 'priority 2)
>       (overlay-put a 'priority `(nil . 1))
>       (overlay-put b 'priority `(nil . 2))
>       ))
> 
> This displays AAAABBBB eventually, but I would expect it to show
> BBBBAAAA, which is what I get if I use "primary" priorities.
> 
> João
> 
> 
> 
> 
> 
> 

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

[João Távora]

On Mon, Jun 19, 2023 at 5:17 PM Milan Jovanovic <milanj@gmail.com> wrote:
>
> João,  is there a reason why (in Eglot) hint parts can’t be merged and only one overlay created ?

Yes, in general you want to keep different properties of different
labels, such as URL links isolated.

> I fix it to create one overlay and I haven’t noticed any issues (I use it only with the rust-analyzer though).
> Don’t know if this is stupid question,  don’t know much about LSP protocol (or Emacs internals).

It's not a stupid question at all, and it's a possibility, but
I have to understand the problem first, and if you haven't
yet understood that, I don't have a Mac OS machine to test.

Before trying fixes, or at least while you're trying them,
please I urge you to provide a reproduction recipe for whatever
you're trying to do.  Your last follow-up bug report is completely strange
to me: in the situation you last described there aren't any
multiple coinciding overlays like in the original report of Krzysztof.

João

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

[Milan Jovanovic]

> On 19. 6. 2023., at 18:34, João Távora <joaotavora@gmail.com> wrote:
> 
> On Mon, Jun 19, 2023 at 5:17 PM Milan Jovanovic <milanj@gmail.com> wrote:
>> 
>> João,  is there a reason why (in Eglot) hint parts can’t be merged and only one overlay created ?
> 
> Yes, in general you want to keep different properties of different
> labels, such as URL links isolated.
Not sure that I understand, I was talking about merging “values” of one “label”, I don’t see that inlay hints code is using any other property from response (other than :value)

>> I fix it to create one overlay and I haven’t noticed any issues (I use it only with the rust-analyzer though).
>> Don’t know if this is stupid question,  don’t know much about LSP protocol (or Emacs internals).
> 
> It's not a stupid question at all, and it's a possibility, but
> I have to understand the problem first, and if you haven't
> yet understood that, I don't have a Mac OS machine to test.
> 
> Before trying fixes, or at least while you're trying them,
> please I urge you to provide a reproduction recipe for whatever
> you're trying to do.  Your last follow-up bug report is completely strange
> to me: in the situation you last described there aren't any
> multiple coinciding overlays like in the original report of Krzysztof.
> 
> João

So, you fix did solve original Krzysztof report (and my original report) for more complex type hints but now I have the same issue with argument hints.

Example:

fn main () {
   let mut c = vec![1,2,3];
   c.insert(0, 0);
}


Inlay type hint of “c” is ok but argument hints for insert() are presented in wrong order:

Instead of    "c.insert(‘index:’ 0, ‘element: ‘ 0)"
i’m getting   "c.insert(‘: index’0, ‘: element’0)”

Trace for this part:

1 -> (make-overlay 384 385 nil nil nil)
1 <- make-overlay: #<overlay from 384 to 385 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> after-string #("index" 0 5 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("index" 0 5 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 384 385 nil nil nil)
1 <- make-overlay: #<overlay from 384 to 385 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> after-string #(": " 0 2 (face eglot-parameter-hint-face)))
1 <- overlay-put: #(": " 0 2 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> priority 1)
1 <- overlay-put: 1
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 384 to 385 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 387 388 nil nil nil)
1 <- make-overlay: #<overlay from 387 to 388 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> after-string #("element" 0 7 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("element" 0 7 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 387 388 nil nil nil)
1 <- make-overlay: #<overlay from 387 to 388 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> after-string #(": " 0 2 (face eglot-parameter-hint-face)))
1 <- overlay-put: #(": " 0 2 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> priority 1)
1 <- overlay-put: 1
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 387 to 388 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 517 518 nil t)
1 <- make-overlay: #<overlay from 517 to 518 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 517 to 518 in main.rs> before-string #(": " 0 1 (face eglot-type-hint-face cursor 1) 1 2 (face eglot-type-hint-face)))
1 <- overlay-put: #(": " 0 1 (face eglot-type-hint-face cursor 1) 1 2 (face eglot-type-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 517 to 518 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 517 to 518 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 517 to 518 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 517 to 518 in main.rs> eglot--overlay t)
1 <- overlay-put: t

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

[João Távora]

On Mon, Jun 19, 2023 at 7:06 PM Milan Jovanovic <milanj@gmail.com> wrote:

> So, you fix did solve original Krzysztof report (and my original report) for more complex type hints but now I have the same issue with argument hints.

Yes, and I've already replied to you that I can't reproduce
your error.  So maybe you should follow the instructions
of

  https://joaotavora.github.io/eglot/#Troubleshooting-Eglot

so that you can provide a bullet-proof reproduction recipe.

So far, you haven't done that.  You just send me snippets of
Rust code and I assume I should paste them into my own
Emacs.  And there, I can't reproduce the problem.

IOW, I don't doubt that there's a problem in Eglot, but I
need you to patiently craft a mail with the full recipe, i.e.
the fullest -- and simplest -- account possible of your
problem.

> Example:
>
> fn main () {
>    let mut c = vec![1,2,3];
>    c.insert(0, 0);
> }
>

Here, again, I see the correct inlay hints.

Here's my recipe.

$ cd /tmp
$ cargo new bla
$ cd bla
$ rust-analyzer --version
rust-analyzer 1 (cd3bf9fe51 2023-06-18)
$ emacs --version
~/Source/Emacs/emacs/src/emacs --version
GNU Emacs 30.0.50
Development version 075e77ac4493 on master branch; build date 2023-06-19.
...
<actually I have eglot.el patched with the latest patch>
$ emacs -Q -f package-initialize src/main.rs -f eglot

Now I wait a little bit for the connection to stabilize and then type in your
main.rs content.  If the inlay hints don't immediately appear, just add and
delete a character anywhere in the buffer.  When they do appear, they appear
correctly.

My rust-mode.el is version 1.0.5, but I've tried successfully with rust-ts-mode
as well.

And by the way, this is the trace of the make-overlay and overlay-put
functions

======================================================================
1 -> (make-overlay 53 54 nil nil nil)
1 <- make-overlay: #<overlay from 53 to 54 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> after-string
#("index: " 0 7 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("index: " 0 7 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 56 57 nil nil nil)
1 <- make-overlay: #<overlay from 56 to 57 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 56 to 57 in main.rs> after-string
#("element: " 0 9 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("element: " 0 9 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 56 to 57 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 56 to 57 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 56 to 57 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 56 to 57 in main.rs> eglot--overlay t)
1 <- overlay-put: t

So, as you can see, the server isn't supplying different hints for
"index" and ":".  So I can't reproduce your error, you must be
using a different version of rust analyzer or something like that.

This is the relevant portion of my Eglot events buffer:

(:jsonrpc "2.0" :id 39 :result
          [(:position (:line 1 :character 12) :label
                      [(:value ": ")
                       (:value "Vec" :location
                               (:uri

"file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
                                :range
                                (:start (:line 395 :character 11) :end
                                        (:line 395 :character 14))))
                       (:value "<i32>")]
                      :kind 1 :textEdits
                      [(:range
                        (:start (:line 1 :character 12) :end
                                (:line 1 :character 12))
                        :newText ": Vec<i32>")]
                      :paddingLeft :json-false :paddingRight
                      :json-false)
           (:position (:line 2 :character 12) :label
                      [(:value "index:" :location
                               (:uri

"file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
                                :range
                                (:start (:line 1434 :character 29)
                                        :end
                                        (:line 1434 :character 34))))]
                      :kind 2 :paddingLeft :json-false :paddingRight t)
           (:position (:line 2 :character 15) :label
                      [(:value "element:" :location
                               (:uri

"file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
                                :range
                                (:start (:line 1434 :character 43)
                                        :end
                                        (:line 1434 :character 50))))]
                      :kind 2 :paddingLeft :json-false :paddingRight t)])

João

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

[Milan Jovanovic]

Looks like overlays render order depends on before-string/after-string property (beside priority).
Type hints overlays are ‘before-string and function parameter hints overlays are ‘after-string (so parameter hint parts are sorted by overlay descending priority).
If you change it to ‘before-string also (and adjust overlay start/end to be as in type hints) it will work as it should.

Btw. I still don’t understand why parts of one hint can’t be simply merged.




Anyway, my recipe to recreate issue:

% rust-analyzer --version
rust-analyzer 1.70.0 (90c54180 2023-05-31)  —> last rustup version (`rustup component add rust-analyzer`)

% /Applications/Emacs.app/Contents/MacOS/Emacs --version                           
GNU Emacs 29.0.91

% ls .emacs.d
auto-save-list elpa
ls .emacs.d/elpa 
archives            eglot-1.15          eglot-1.15.signed   eldoc-1.14.0        eldoc-1.14.0.signed gnupg

(eglot.el is patched with diff from João email)

% cargo new inlay-hints

>>> paste  this code into inlay-hints/src/main.rs

fn main() {
  let mut c = vec![1,2,3];
  c.insert(0, 0);
}

<<<<

% cd inlay-hints

% /Applications/Emacs.app/Contents/MacOS/Emacs src/main.rs -f rust-ts-mode -f eglot


Eglot events:

(:jsonrpc "2.0" :id 13 :result
	  [(:position
	    (:line 1 :character 11)
	    :label
	    [(:value ": ")
	     (:value "Vec" :location
		     (:uri "file:///Users/milan/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs" :range
			   (:start
			    (:line 395 :character 11)
			    :end
			    (:line 395 :character 14))))
	     (:value "<i32>")]
	    :kind 1 :paddingLeft :json-false :paddingRight :json-false)
	   (:position
	    (:line 2 :character 11)
	    :label
	    [(:value "index" :location
		     (:uri "file:///Users/milan/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs" :range
			   (:start
			    (:line 1434 :character 29)
			    :end
			    (:line 1434 :character 34))))
	     (:value ":")]
	    :kind 2 :paddingLeft :json-false :paddingRight t)
	   (:position
	    (:line 2 :character 13)
	    :label
	    [(:value "element" :location
		     (:uri "file:///Users/milan/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs" :range
			   (:start
			    (:line 1434 :character 43)
			    :end
			    (:line 1434 :character 50))))
	     (:value ":")]
	    :kind 2 :paddingLeft :json-false :paddingRight t)])



Trace output:
======================================================================
1 -> (make-overlay 25 26 nil t)
1 <- make-overlay: #<overlay from 25 to 26 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> before-string #(": " 0 1 (face eglot-type-hint-face cursor 1) 1 2 (face eglot-type-hint-face)))
1 <- overlay-put: #(": " 0 1 (face eglot-type-hint-face cursor 1) 1 2 (face eglot-type-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 25 26 nil t)
1 <- make-overlay: #<overlay from 25 to 26 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> before-string #("Vec" 0 3 (face eglot-type-hint-face)))
1 <- overlay-put: #("Vec" 0 3 (face eglot-type-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> priority 1)
1 <- overlay-put: 1
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 25 26 nil t)
1 <- make-overlay: #<overlay from 25 to 26 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> before-string #("<i32>" 0 5 (face eglot-type-hint-face)))
1 <- overlay-put: #("<i32>" 0 5 (face eglot-type-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> priority 2)
1 <- overlay-put: 2
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 25 to 26 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 51 52 nil nil nil)
1 <- make-overlay: #<overlay from 51 to 52 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> after-string #("index" 0 5 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("index" 0 5 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 51 52 nil nil nil)
1 <- make-overlay: #<overlay from 51 to 52 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> after-string #(": " 0 2 (face eglot-parameter-hint-face)))
1 <- overlay-put: #(": " 0 2 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> priority 1)
1 <- overlay-put: 1
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 51 to 52 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 53 54 nil nil nil)
1 <- make-overlay: #<overlay from 53 to 54 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> after-string #("element" 0 7 (face eglot-parameter-hint-face)))
1 <- overlay-put: #("element" 0 7 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> priority 0)
1 <- overlay-put: 0
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (make-overlay 53 54 nil nil nil)
1 <- make-overlay: #<overlay from 53 to 54 in main.rs>
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> after-string #(": " 0 2 (face eglot-parameter-hint-face)))
1 <- overlay-put: #(": " 0 2 (face eglot-parameter-hint-face))
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> priority 1)
1 <- overlay-put: 1
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--inlay-hint t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> evaporate t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--overlay t)
1 <- overlay-put: t
======================================================================
1 -> (overlay-put #<overlay from 176 to 177 in *ielm*> priority 1000)
1 <- overlay-put: 1000
======================================================================
1 -> (overlay-put #<overlay from 176 to 177 in *ielm*> face show-paren-match)
1 <- overlay-put: show-paren-match
======================================================================
1 -> (overlay-put #<overlay from 164 to 165 in *ielm*> priority 1000)
1 <- overlay-put: 1000
======================================================================
1 -> (overlay-put #<overlay from 164 to 165 in *ielm*> face show-paren-match)
1 <- overlay-put: show-paren-match



> On 19. 6. 2023., at 21:08, João Távora <joaotavora@gmail.com> wrote:
> 
> On Mon, Jun 19, 2023 at 7:06 PM Milan Jovanovic <milanj@gmail.com> wrote:
> 
>> So, you fix did solve original Krzysztof report (and my original report) for more complex type hints but now I have the same issue with argument hints.
> 
> Yes, and I've already replied to you that I can't reproduce
> your error.  So maybe you should follow the instructions
> of
> 
>  https://joaotavora.github.io/eglot/#Troubleshooting-Eglot
> 
> so that you can provide a bullet-proof reproduction recipe.
> 
> So far, you haven't done that.  You just send me snippets of
> Rust code and I assume I should paste them into my own
> Emacs.  And there, I can't reproduce the problem.
> 
> IOW, I don't doubt that there's a problem in Eglot, but I
> need you to patiently craft a mail with the full recipe, i.e.
> the fullest -- and simplest -- account possible of your
> problem.
> 
>> Example:
>> 
>> fn main () {
>>   let mut c = vec![1,2,3];
>>   c.insert(0, 0);
>> }
>> 
> 
> Here, again, I see the correct inlay hints.
> 
> Here's my recipe.
> 
> $ cd /tmp
> $ cargo new bla
> $ cd bla
> $ rust-analyzer --version
> rust-analyzer 1 (cd3bf9fe51 2023-06-18)
> $ emacs --version
> ~/Source/Emacs/emacs/src/emacs --version
> GNU Emacs 30.0.50
> Development version 075e77ac4493 on master branch; build date 2023-06-19.
> ...
> <actually I have eglot.el patched with the latest patch>
> $ emacs -Q -f package-initialize src/main.rs -f eglot
> 
> Now I wait a little bit for the connection to stabilize and then type in your
> main.rs content.  If the inlay hints don't immediately appear, just add and
> delete a character anywhere in the buffer.  When they do appear, they appear
> correctly.
> 
> My rust-mode.el is version 1.0.5, but I've tried successfully with rust-ts-mode
> as well.
> 
> And by the way, this is the trace of the make-overlay and overlay-put
> functions
> 
> ======================================================================
> 1 -> (make-overlay 53 54 nil nil nil)
> 1 <- make-overlay: #<overlay from 53 to 54 in main.rs>
> ======================================================================
> 1 -> (overlay-put #<overlay from 53 to 54 in main.rs> after-string
> #("index: " 0 7 (face eglot-parameter-hint-face)))
> 1 <- overlay-put: #("index: " 0 7 (face eglot-parameter-hint-face))
> ======================================================================
> 1 -> (overlay-put #<overlay from 53 to 54 in main.rs> priority 0)
> 1 <- overlay-put: 0
> ======================================================================
> 1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--inlay-hint t)
> 1 <- overlay-put: t
> ======================================================================
> 1 -> (overlay-put #<overlay from 53 to 54 in main.rs> evaporate t)
> 1 <- overlay-put: t
> ======================================================================
> 1 -> (overlay-put #<overlay from 53 to 54 in main.rs> eglot--overlay t)
> 1 <- overlay-put: t
> ======================================================================
> 1 -> (make-overlay 56 57 nil nil nil)
> 1 <- make-overlay: #<overlay from 56 to 57 in main.rs>
> ======================================================================
> 1 -> (overlay-put #<overlay from 56 to 57 in main.rs> after-string
> #("element: " 0 9 (face eglot-parameter-hint-face)))
> 1 <- overlay-put: #("element: " 0 9 (face eglot-parameter-hint-face))
> ======================================================================
> 1 -> (overlay-put #<overlay from 56 to 57 in main.rs> priority 0)
> 1 <- overlay-put: 0
> ======================================================================
> 1 -> (overlay-put #<overlay from 56 to 57 in main.rs> eglot--inlay-hint t)
> 1 <- overlay-put: t
> ======================================================================
> 1 -> (overlay-put #<overlay from 56 to 57 in main.rs> evaporate t)
> 1 <- overlay-put: t
> ======================================================================
> 1 -> (overlay-put #<overlay from 56 to 57 in main.rs> eglot--overlay t)
> 1 <- overlay-put: t
> 
> So, as you can see, the server isn't supplying different hints for
> "index" and ":".  So I can't reproduce your error, you must be
> using a different version of rust analyzer or something like that.
> 
> This is the relevant portion of my Eglot events buffer:
> 
> (:jsonrpc "2.0" :id 39 :result
>          [(:position (:line 1 :character 12) :label
>                      [(:value ": ")
>                       (:value "Vec" :location
>                               (:uri
> 
> "file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
>                                :range
>                                (:start (:line 395 :character 11) :end
>                                        (:line 395 :character 14))))
>                       (:value "<i32>")]
>                      :kind 1 :textEdits
>                      [(:range
>                        (:start (:line 1 :character 12) :end
>                                (:line 1 :character 12))
>                        :newText ": Vec<i32>")]
>                      :paddingLeft :json-false :paddingRight
>                      :json-false)
>           (:position (:line 2 :character 12) :label
>                      [(:value "index:" :location
>                               (:uri
> 
> "file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
>                                :range
>                                (:start (:line 1434 :character 29)
>                                        :end
>                                        (:line 1434 :character 34))))]
>                      :kind 2 :paddingLeft :json-false :paddingRight t)
>           (:position (:line 2 :character 15) :label
>                      [(:value "element:" :location
>                               (:uri
> 
> "file:///usr/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs"
>                                :range
>                                (:start (:line 1434 :character 43)
>                                        :end
>                                        (:line 1434 :character 50))))]
>                      :kind 2 :paddingLeft :json-false :paddingRight t)])
> 
> João

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

[João Távora]

Milan Jovanovic <milanj@gmail.com> writes:

> Btw. I still don’t understand why parts of one hint can’t be simply
> merged.

They could be merged but devising logic and heuristics to do it
correctly would hardly be "simple".  In this particular case, they could
be merged, becasue the ':' label part doesn't have any properties
clashing with the 'index' name-of-parameter label part.  But in general,
that isn't necessarily so, and Eglot is a generic Eglot client, not just
catering to the rust-analyzer server which provides these very fine
grained labels.  So the simplest solution is taken and it is complex
enough.

So here the disadvantages outweigh the benefits.

> Anyway, my recipe to recreate issue:
>
> % rust-analyzer --version
> rust-analyzer 1.70.0 (90c54180 2023-05-31)  —> last rustup version
> (`rustup component add rust-analyzer`)

Thanks.  This was key.  I've reproduced the problem (here, I didn't need
Mac OS) and pushed a fix to emacs-29.  The fix will appear in master
soon and thus also in upcoming Eglot 1.16.

João

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

[Eli Zaretskii]

> From: Milan Jovanovic <milanj@gmail.com>
> Date: Mon, 19 Jun 2023 23:05:49 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Eli Zaretskii <eliz@gnu.org>,
>  Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
>  64101@debbugs.gnu.org
> 
> Looks like overlays render order depends on before-string/after-string property (beside priority).

Don't you expect that?  If some text has both before-string and
after-string overlays, which one(s) will you expect to see before the
other one?

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

[Milan Jovanovic]

I do expect that but I’m talking about order of overlays that have the same start/end (and all of them have the same before-or-after-string property).
If you have more than one overlay with the same start/end and all of them have the same before-or-after-string property one order will be ascending and other descending (in regard to priority).
At least that is why I’ve observed while looking at the Eglot issue.

> On 20. 6. 2023., at 13:10, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Milan Jovanovic <milanj@gmail.com>
>> Date: Mon, 19 Jun 2023 23:05:49 +0200
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>> Eli Zaretskii <eliz@gnu.org>,
>> Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
>> 64101@debbugs.gnu.org
>> 
>> Looks like overlays render order depends on before-string/after-string property (beside priority).
> 
> Don't you expect that?  If some text has both before-string and
> after-string overlays, which one(s) will you expect to see before the
> other one?

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

[Eli Zaretskii]

> From: Milan Jovanovic <milanj@gmail.com>
> Date: Tue, 20 Jun 2023 13:32:04 +0200
> Cc: João Távora <joaotavora@gmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
>  64101@debbugs.gnu.org
> 
> I do expect that but I’m talking about order of overlays that have the same start/end (and all of them have the same before-or-after-string property).
> If you have more than one overlay with the same start/end and all of them have the same before-or-after-string property one order will be ascending and other descending (in regard to priority).

And you don't expect that from the Emacs display?

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

[Milan Jovanovic]

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

Well, from reading this thread I expected it to be sorted by priority.

On Tue, Jun 20, 2023 at 2:01 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Milan Jovanovic <milanj@gmail.com>
> > Date: Tue, 20 Jun 2023 13:32:04 +0200
> > Cc: João Távora <joaotavora@gmail.com>,
> >  Stefan Monnier <monnier@iro.umontreal.ca>,
> >  Krzysztof Klimonda <kklimonda@syntaxhighlighted.com>,
> >  64101@debbugs.gnu.org
> >
> > I do expect that but I’m talking about order of overlays that have the
> same start/end (and all of them have the same before-or-after-string
> property).
> > If you have more than one overlay with the same start/end and all of
> them have the same before-or-after-string property one order will be
> ascending and other descending (in regard to priority).
>
> And you don't expect that from the Emacs display?
>

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

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

[Eli Zaretskii]

> From: Milan Jovanovic <milanj@gmail.com>
> Date: Tue, 20 Jun 2023 15:34:42 +0200
> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 
> 	kklimonda@syntaxhighlighted.com, 64101@debbugs.gnu.org
> 
> Well, from reading this thread I expected it to be sorted by priority.

They are, if they have different priorities and the same overlay
properties.

The problem was with the SECONDARY priority, since (according to
Stefan) the display code doesn't know about that feature.  I didn't
yet have time to look at that code.

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

[João Távora]

On Tue, Jun 20, 2023 at 2:34 PM Milan Jovanovic <milanj@gmail.com> wrote:
>
> Well, from reading this thread I expected it to be sorted by priority.

I for one also expected that, though the actual behaviour is defensible
too (not to mention the second problem that Milan reported which stemmed
from my misplaced expectation is now also fixed in emacs-29, hopefully,
I'm just waiting for Milan to confirm).

More specifically, I expected setting monotonically increasing priorities
as one creates coinciding overlays one after the other to have the exactly
the same effect (wrt displaying before-string and after-string)
as creating these overlays _without_ setting priorities on a GNU/Linux system
with the default memory allocation routines (which as Stefan clarified is
a last-resort fallback).

IOW:

(setq a (make-overlay 10 20))
(setq b (make-overlay 10 20))
(overlay-put a 'after-string "aaa")
(overlay-put b 'after-string "bbb")

has a half-predictable effect on Linux.  In fact it displays
exactly the same as doing that with 'before-string'.

I would expect that adding

(overlay-put a 'priority 1)
(overlay-put b 'priority 2)

would have now a fully-predictable _same_ effect on every system.  The
fully-predictable requirement is fullfilled alright, but the display order
is reversed if 'after-string' is used.

But, again, I guess the behaviour _with_ priorities is defensible too.
Though it's not really obvious.

João