Re: Eglot "inlay hints" landed

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

On Fri, Feb 24, 2023 at 7:35 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  dalal.chinmay.0101@gmail.com,
> >   emacs-devel@gnu.org,  dimitri@belopopsky.com,  luangruo@yahoo.com
> > Date: Thu, 23 Feb 2023 20:08:41 -0500
> >
> > Yes and no: yes, there are already cases where the jit-lock-context
> > heuristic of refreshing everything *after* a modification is not
> > sufficient
>
> If a jit-lock client is smart enough, it should itself install an
> after-change function to remove the 'fontified property from the
> portions of buffer text affected by a change that are before the first
> changed position (or maybe even in other buffers).

Thanks, I was going to ask about that. I suppose this is how one
marks sections of a buffer "dirty" or invalidatest them so that
jit-lock knows it must run over them again when it sees fit.

If it works with other buffers as well, it might provide an
elegant solution to the "A affects B" scenario we discussed
earlier.

> > but as a general rule programming languages are designed for
> > "forward-only parsing" so it's unusual for a change at POS to affect the
> > parsing before POS
>
> Strictly speaking, this is inaccurate: a change in the middle of a
> line could very well affect parsing of that entire line, so it in
> effect affects everything from the beginning of that line (perhaps
> even more, if that line is a continued line, in the language syntax).
> But jit-lock is supposed to already account for that, and call the
> fontification-functions with START set to the beginning of the line,
> unless I'm misremembering.  (You already know all that, but maybe João
> doesn't.)

Thanks, I think I can confirm this.  I've observed this behaviour.
Jit lock starts in the beginning of the line to end of the line
in a small chunk containing the small changed region, only then
proceeds to larger chunks (after some jit-lock-contextual-time,
apparently).

> > > 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.
> > [ And of course, there are also those few rare modes that don't use
> >   jit-lock-context at all.  ]
>
> jit-lock doesn't use window-end.  It can't, really: the results of
> fontification could affect where the window ends, which is why
> window-end is only updated when redisplay of a window successfully
> finishes, which is way after jit-lock did its job.
>
> That is why jit-lock calls fontification-functions with END that is
> arbitrarily computed from START; this is controlled by
> jit-lock-chunk-size.  And a function called via
> fontification-functions could legitimately decide it fontifies more
> than just the chunk for which it was called.

And Eglot's eglot--update-hints is indeed one such function.  The
coalescing of small jit-lock chunks is very "generous" and it will
request inlay hints for things in the middle that jit-lock didn't
strictly think are necessary.  This works out well in my testing
with the latest version of the feature installed in emacs-29.

> (Again, you already know all that.  I'm writing this to avoid
> potential misunderstandings and confusion.)

Thanks for the clarifications.

João