bug#70036: a fix that

[Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

João Távora <joaotavora@gmail.com> writes:

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

Absolutely, it could be. But with these latest changes the felt lag is
gone.

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

I can try, but these repros are hard, because it is hard to find an open
source java project where I easily can construct similar scenarios. And
also time.

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

Yes, sure. Not arguing there. Just noticing that what we're doing here
isn't too different.

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

:thumbsup:

Theo