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

[Tim Cross <theophilusx@gmail.com>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

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

I think I agree. I've often seen the criticism that LSP based solutions
are no good because of poor performance arising from the use of JSON as
the communication format. 

As someone who has done his share of web development and is very
familiar with the pros and cons of JSON and alternative formats which (I
think) are far superior, I can udnerstand where this concern can come
from. 

However, having used LSP based setups (lsp-mode and eglot) fro quite
some time on some large projects with many files and some large source
files and in a couple of different languages, I have to say I've not
noticed performance issues at all. I have run into other issues, most of
which have been resolved. I did find with eglot that it was important
to ensure the packages it users were up-to-date (i.e. xref, flymake,
eldoc etc). 

What I have observed is that unsurprisingly, results are very dependent
on the language server you are using. For example, I switched the LSP
server I was using for Javascript and immediately experienced a much
better result. Actually, this was one of the nice aspects of using an
LSP based work flow. Changeing LSP server was a simple as downloading
the server executable and changing one variable in my client config. 

I have not used LSP for font locking, but have used it for indentation
and it worked fine with no observable performance issues like typing lag
etc.

The other aspect of using LSP which I've found interesting, but really
only as something to hack/playh with, has been setting up your own LSP
server for a specific language. I experimented using Clojure and Raku
and was surprised how quickly/easily you could add functionality to my
editor, primarily as I was able to leverage of built-in functionality
of the languages I was working with. I think this ability to leverage of
the target languages built-in features combined with a smaller code base
and reduced maintenance within the editor core is what gives the LSP
architecture an edge over solutions like tree-sitter. The fact it can be
used with multiple different editors is the sugar on top.

However, if the effort has been done to add tree-sitter support for a
language and it is maintained, then it will likely to perform better in
many cases and could well be the preferred choice for many users.