GNU bug report logs -
#64101
29.0.91; Eglot inlay hints rendered out of order
Previous Next
Full log
Message #38 received at 64101 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jun 17, 2023 at 4:50 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Sat, 17 Jun 2023 15:29:38 +0100
> > Cc: kklimonda <at> syntaxhighlighted.com, 64101 <at> debbugs.gnu.org,
> > monnier <at> 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
This bug report was last modified 2 years and 60 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.