[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: Theodor Thornhill
Subject: Re: Renaming eglot -- or at least add an alias?
Date: Thu, 13 Oct 2022 18:11:40 +0200

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. 

reply via email to

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