Re: Eglot "inlay hints" landed

["João Távora" <joaotavora@gmail.com>]

On Thu, Feb 23, 2023 at 11:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Chinmay Dalal <dalal.chinmay.0101@gmail.com>
> > Cc: joaotavora@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com,
> >  luangruo@yahoo.com
> > Date: Thu, 23 Feb 2023 15:25:21 +0530
> >
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Can it be instead done in such a way that initially (when loading a new
> > >> file) they are requested for the whole buffer, then on subsequent
> > >> changes they are only requested for the visible regions.
> > >
> > > Why would we want that?
> >
> > It will solve this problem:
> >
> > >> > When
> > >> > scrolling a window, it may take a short amount of time for inlay hints
> > >> > to "pop in".
>
> So would using jit-lock-register, which was proposed here.

The "pop-in" delay is just a function of the intentional
bandwidth-conserving timer delay + the normal LSP interprocess
communication delay. Any jit/lazy Emacs-side solution
is going to have to deal at least with the second addend of
that sum.

jit-lock-register was unknown to me.  It seems to rely on some
heuristic to know what regions need to be "refontified".  I wonder
if the heuristic will be accurate for inlay hints, since changing
void foo(int bar){...}  to void foo(int baz){...} in one part of
the buffer doesn't usually change the fontification of the rest
of the buffer.  But it might very well invalidate the inlay hints
everywhere.

In fact the invalidation impact is not just in the same buffer,
but potentially all other buffers (all the ones where a call to
'foo' is found).  Eglot's inlay hints implementation doesn't
handle this edge case.  Though I don't think it would be
extremely hard to, it doesn't seem extremely relevant for what
is usually a "best effort" helper feature from the LSP side.

João