bug#70036: a fix that

[João Távora]

On Fri, Apr 19, 2024 at 7:09 AM Theodor Thornhill <theo@thornhill.no> wrote:

> you've also noted earlier. I have an even stronger computer, a 2023 P1
> gen 5, I believe, running ubuntu. Some servers send _all_ diagnostics on
> every keystroke.

That could be, but what servers are these?

Thought it would never be "on every keystroke" though.  As you probably
know, Eglot bunches them up in didChange notifications, and you can
can even be the size of these bunches.

> > So my perception is that it must have spent around 4% of 1 second in
> > file-truename.
> >
> > Anyway the reason this shows in this profile is because this project
> > with this particular server sends a lot of publishDiagnostics upfront.
> > That's OK.  Gopls is a very good server.  I think I see a fix.  But can
> > you qualitatively describe the Eglot experience.  Do you notice any
> > input lag or something like that? With this project?  I didn't feel _any_
> > lag.
> > Super snappy.  Maybe the JSON serde kicking in?
> >
>
> In this particular project I don't notice any input lag. But on every
> java project at work I absolutely do.

But that could be down to other reasons Theodor.  We would need data
for that server too.  Last time I tried jdtls (on a docker-based TRAMP
setup, described somewhere in the mailing list), it was snappy.

If you make a simple recipe like this one I can absolutely
try though.  The difficulty in that one was TRAMP.


> > Anyway, the idea I suggested earlier is in the patch after  my sig.
> >
> > Let's think:  LSP's publishDiagnostics coming from the server deals
> > in URIs, right?  And we inform the LSP server about URIs, too, right?
> > So the URI is always LSP's idea of the resource identifier (and it likes
> > to have truename URI).
>
> Sure, like in my key/value store. (apart from symlinking)

The other difference is it uses buffer-local variables as the
natural "per-buffer" storage method.

> Could we rather use eglot--managed-buffers, like in my patch? there
> shouldn't be a need to loop through say 200 buffers that are unrelated
> to the project in question, right? Apart from this I agree, and will try
> it.

Of course, that's a good improvement.

João