Re: Eglot "inlay hints" landed

[Eli Zaretskii]

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

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

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

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