[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akib Azmain Turja
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Fri, 14 Oct 2022 09:56:38 +0600

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]