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

[Theodor Thornhill]

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.