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

[Stephen Leake <stephen_leake@stephe-leake.org>]

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.

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.

> 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.

-- 
-- Stephe