Re: Eglot "inlay hints" landed

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

Eli Zaretskii <eliz@gnu.org> writes:

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

Ah, if it works with "parts of the buffer about to be displayed", then it
should be good, yes.  But the docstring of jit-lock-register says "START
and END indicating the region that needs to be (re)fontified".  If that
is guaranteed to always match the "region of the buffer about to be
displayed" in the window, then we're good.

I wonder if it also removes the need for the "smoothing" timers I am
using.

But note though, that while this has promise for a simpler and more
robust implementation, it will _not_ solve the "pop-in" delay.  The
effects that Eglot's jit-lock-register FUN fontification function
produces in the buffer are guaranteed _not_ be finished by the time FUN
returns (unless these FUN is allowed to be slow and blocking, which I
really don't think is the point).  That's what I meant by "any
Emacs-side solution [...] deal with [the normal LSP interprocess
communication] delay".

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

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

Yes, but two buffers A and B might already be showing in some window.
If you do the change in buffer A and it affects B, then in the current
version, the parts of A being show in windows will be updated, but B the
parts of B being shown in some other windows will not.

João

PS: On an unrelated note, I pushed this to emacs-29.  If you wish me to
revert the inlay hints implementation and do all this work in master,
it's fine by me.  In practice, it won't really make that much of a
difference because Eglot (along with being a new emacs-29 feature) is
also a GNU ELPA :core package and emacs-29 users will have access to the
latest and greatest features and bugfixes relatively easily anyway.