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