Re: Eglot "inlay hints" landed

[João Távora]

On Fri, Feb 24, 2023 at 11:33 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Fri, 24 Feb 2023 10:42:26 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, dalal.chinmay.0101@gmail.com,
> >       emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com
> >
> > On Fri, Feb 24, 2023 at 7:35 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > 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.
>
> I don't see why it wouldn't work.

Yes.  I never said it wouldn't :-) (and you never said I said,
I'm just clarifying :-).

Anyway, there is also this to this topic.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_inlayHint_refresh

an "inlay hint refresh request" from the server.  A separate
capability apparently designed to cover this case.  I don't
know how it fits into the equation but I would think it was
designed for editors with none of our jit-capabilities.  Maybe
it's mostly useless to us now, especially given its poor
interface (it's just a bare request with no parameters).

It does illustrate the typical LSP line of reasoning: "the server
knows best, because the server knows the language".  IOWs the LSP
server knowledge stands for Emacs  major-mode knowledge.  The
difference here is that the interfaces to extract that knowledge
from the server are very limited or poorly designed.

João