Re: Renaming eglot -- or at least add an alias?

[Akib Azmain Turja]

Theodor Thornhill <theo@thornhill.no> writes:

> On 13 October 2022 12:20:13 CEST, Stephen Leake 
> <stephen_leake@stephe-leake.org> wrote:
>>Theodor Thornhill <theo@thornhill.no> writes:
>>
>>> On 13 October 2022 02:47:51 CEST, Stephen Leake 
>>> <stephen_leake@stephe-leake.org> wrote:
>>>>Richard Stallman <rms@gnu.org> writes:
>>>>
>>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>>
>>>>>   > > Because all of the interaction between server and client in lsp is 
>>>>> json
>>>>>   > > there's a huge overhead with parsing and shipping things into the 
>>>>> emacs
>>>>>   > > user interface.  So IMO what tree-sitter is good at should be left 
>>>>> to
>>>>>   > > tree-sitter.
>>>>
>>>>Premature optimization.
>>>>
>>>
>>> Why do you say that? 
>>
>>Because it gives a supposed cause without evidence of an actual problem.
>>
>>> I've been using lsp for a long time, and typing lag can get unbearable
>>> with servers that sends too much stuff. When 20k completions
>>> containing _full_ documentation for every result that json gets
>>> humongous. 
>>
>>Ok, that's actual data. On the other hand, did you measure different
>>parts of the process, so you are sure that the json is the bottleneck,
>>and not something else? It's not clear just from this description that a
>>tree-sitter implementation would be faster.
>>
>
> Yes I did,at the time. Though I cannot find the issue at hand, but it was 
> related to Elm-language-server if memory serves me right. 
>
>
>>In addition, LSP supports sending the documentation later, after the user
>>has actually looked at a completion item, using a completionItem/resolve
>>request. So this sounds like a specific client or server implementation
>>problem more than an inherent LSP problem.
>>
>
> Sure, but that's life. Nonconforming servers are everywhere, and these
> issues are bound to happen. If something as important and simple as
> colors and indentation would be unusable because of a bug in a
> transitive dependency we have a much bigger problem, imo. Tree-sitter
> will not cause us these headaches as easily.
>
>
>>> Adding syntax highlights on top of that isn't advisable, considering
>>> emacs nonmultithreaded nature.
>>
>>Syntax highlighting, mediated by font-lock, should only ever send small
>>amounts of data; one screen full at a time. That is if the server
>>supports the textDocument/semanticTokens/range request, and not just the
>>textDocument/semanticTokens/full request.
>>
>
> Yes, and yet again we are at the mercy of the specific server. Using
> tree-sitter we can much more reliably resolve the situation on our
> own. Of course, in both cases the tech is new and will mature, but to
> me tree-sitter seems like the obvious winner.
>

LSP is too flexible to block the editor.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

signature.asc
Description: PGP signature