Re: Eglot "inlay hints" landed

[João Távora]

On Fri, Feb 24, 2023 at 1:08 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> In your case, I suspect for the affected language servers there's not much
> more we can do but to say that the whole buffer's inlays need to be
> recomputed after a change.

I'd really like to avoid that.  If it comes to that, and the problem
really is annoying enough (it might not be, and inlay hints are usually
a best-effort thing by the servers themselves) then I think going back
to the window-scroll-functions might be a better option.  It doesn't have this
problem.

> > To do this, we use a jit-lock implementation detail,
> > jit-lock-context-unfontify-pos, which tells us that the contextual
> > fontification has just finished.  Not sure how brittle it is, but it
> > seems to work reasonably.
>
> I think it won't work reliably in the case where the "immediate"
> jit-lock refresh happens to cover everything until window-end (e.g. we
> just inserted chunk of text that ends after window-end).  In that case
> the jit-lock-context thingy will just mark the rest of the buffer as
> "not fresh" but won't call your fontification function at all.

Yes, I noticed something like that: many immediate small jit lock calls
where the condition was true.

> [ And of course, there are also those few rare modes that don't use
>   jit-lock-context at all.  ]
>
> I think using your own timer is probably the better option.  I'd
> make it wait for `eglot-lazy-inlay-hints` rather than (+
> eglot-lazy-inlay-hints jit-lock-context-time), but I'd give it as
> default value a value computed from `jit-lock-context-time`.

Using a timer is necessary, but I've found that a 0-second timer is
sufficient to coalesce "well".  But we only fire the timer if
the "unfontify-pos == point-max" condition is met.  Then we don't
need to compete with jit-lock-context-timer, which is really the part I found
very bad.

I've pushed this last version to emacs-29.  Have a look there,
please.  And thanks for the insight!

João