[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70036: a fix that
From: |
Theodor Thornhill |
Subject: |
bug#70036: a fix that |
Date: |
Fri, 19 Apr 2024 11:10:16 +0200 |
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
- bug#70036: a fix that, (continued)
- bug#70036: a fix that, Theodor Thornhill, 2024/04/18
- bug#70036: a fix that, João Távora, 2024/04/18
- bug#70036: a fix that, João Távora, 2024/04/18
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that,
Theodor Thornhill <=
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, Theodor Thornhill, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, Ihor Radchenko, 2024/04/19
- bug#70036: a fix that, Eli Zaretskii, 2024/04/19
- bug#70036: a fix that, Ihor Radchenko, 2024/04/30
- bug#70036: a fix that, João Távora, 2024/04/19
- bug#70036: a fix that, João Távora, 2024/04/19