Re: Eglot "inlay hints" landed

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 23 Feb 2023 11:23:40 +0000
> Cc: Chinmay Dalal <dalal.chinmay.0101@gmail.com>, emacs-devel@gnu.org, 
>       dimitri@belopopsky.com, luangruo@yahoo.com
> 
> On Thu, Feb 23, 2023 at 11:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > 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.

I don't understand: using jit-lock-register just means your code is
called via jit-lock's fontification-functions instead of
window-scroll-functions that you used.  Any problems with LSP delays
that you deal with in the latter should be possible in the former as
well, no?  Or what am I missing?

The advantages of using jit-lock are that (a) it is more accurate in
telling you which parts of the buffer are about to be displayed, and
(b) it is much more reliable, because window-scroll-functions are not
necessarily called when something changes on display.  For example, we
lately discovered that pixel-scroll-precision-mode doesn't call
window-scroll-functions.

> jit-lock-register was unknown to me.  It seems to rely on some
> heuristic to know what regions need to be "refontified".

It isn't a heuristic.  jit-lock is called from the display engine,
which always has a pretty good idea which parts of the buffer it needs
to show on the screen.

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

The display engine doesn't know which parts will be affected by the
change, it only knowes what's on display and what isn't.  The function
called via fontification-functions are supposed to know their job, and
look at the parts of the buffer according to their needs; jit-lock
just gives them a hint in the form of the region of the buffer it
wants to display.

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

We don't need to make the overlays until the buffer is shown in some
window, right?