Hacker News Reader

Comment by antoineMoPa | Hacker News Reader

I'm a bit disappointed at the features of the included lsp client. I went back to lsp-mode.

Also I feel like performance could be improved a lot, but that's probably an issue in my particular setup.

If someone has an efficient lsp-mode + typescript-mode + eslint checks, I'd be happy to see how you achieved that.

While lsp has brought the best utilities that used to be locked away inside IDEs. I just don't see how you can build upon it when its been shown to struggle pretty much since the beginning.

JSON is okay if you need a format that is human readable but how did the engineers at microsoft ever think that it was a good choice for interprocess communication?. Most of the work is wasted on decoding the json itself. We should not have to increase the interval between request and batch calls in order to make it usable.

Have you profiled things and have data to show JSON handling is the root of the performance issues?

Not the person you are replying to, but the JSON performance of Emacs was a well-known thorn in the side for using LSP.

Further details...

... from the same source as the top post: https://www.masteringemacs.org/article/speed-up-emacs-libjan...

... from lsp-mode: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-...

Ah, ok, I get what you mean, but those are not inherent JSON issues. After all, VS Code & co use the exact same protocol in a speedy fashion.

It's Emacs needing to be configured to use faster JSON libraries.

The original comment was complaining about JSON as a format itself, and my argument is that unless you need super high performance, JSON is more than enough. And it's not like LSP is passing around GB of data every second, let's be real here :-)

LSP as a protocol feels like somebody documented IDE features, then exposed those directly at the protocol level. It's absurd. When last I checked, I could register a function to be used to apply syntax highlighting when the LSP server identifies a change, but you couldn't make any explicit queries against the known parts of the syntax.

I wanted to query the LSP server to tell whether the point was currently located within a string, but as far as I could tell, the LSP server couldn't be queried for the syntax type. You can ask for "selection suggestions", you can ask for "semantic tokens" within a specific range, but you cannot ask for the semantic token containing a single specific point.

That's exactly what LSP is. Notice that it was invented by Microsoft and it becomes a lot less surprising.

VS Code can achieve much more performant editing with the same server, so there is no excuse for emacs to be slow.

My experience is that VS Code has a tremendous amount of input lag, to the point that I need to wait for a search prompt to focus before I can start my query. Emacs, on the other hand, is incredibly responsive, and even when running over a slow SSH connection has properly buffered inputs so I don’t need to wait.

Emacs can achieve much more performant editing with the same server, so there’s no excuse for VS Code to be so slow.

VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable.

If you invested the time to configure Emacs to mimic VS code's completion- instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, i.e. the entire editor stutters on every keystroke, because the garbage collector is constantly blocking the UI thread. The performance limitations are widely known. It's the reason yyoncho, the creator of LSP-mode, forked Emacs to explore adding multithreading to address the issue [0].

But I can't see this being fixed anytime soon, because there are a fleet of intellectually dishonest zealots on the internet that refuse to acknowledge it's an issue, and will flame anyone who brings it up.

As a result, when new users try out Emacs and see that the performance sucks, many of them will instantly uninstall and return to VS code, and the userbase suffers.

[0] https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...

> instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged,

I am using lsp-mode enhanced autocompletion (using company.el) and I have never observed such a problem. I set the autcompletion delay to 0.0 in my case and work on 1k LOC modules.

If you enjoy VS code, I am glad for you. It is certainly a good editor. But don't post generalized slurs against Emacs if you obviously haven't used it for long.

Performance issues can happen but that highly depends on the context. What combination of language server, language server client and what language is causing this?

Edit:

If you are new to "lsp-mode" and you have performance issues, take a look here:

https://emacs-lsp.github.io/lsp-mode/page/performance/#json-...

Also consider trying other LSP servers if available. For popular languages there are usually several alternatives to choose from:

https://langserver.org/

I mentioned that bringing up performance issues will bring you insults and dismissal, and you saw fit to reply with:

> I have never observed such a problem

> don't post generalized slurs against Emacs

> If you enjoy VS code, I am glad for you.

> you obviously haven't used it for long

I guess it did not occur to you that you are immediately proving my point.

To answer your question, the context is literally every single language server. Not only with autocompletion delay to 0.0, but also setting the minimum prefix to 1, so that it activates on every keystroke; the default is 3. The fuzzy completion cannot be configured out of the box, of course, it requires another extension. I posted a thread with much detail on why it occurs.

You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.

Well, Emacs has indeed a problem with blocking because it is single-threaded. To resolve that issue internally it also maintains an event loop being used to drive async. functions calls. But not all extensions leverage that yet. But I doubt the problem described in that reddit thread you cited is really caused by that. It sounds more likely the author of that Emacs fork experienced an issue with inter process communication. Who knows because there is no detailed context given.

I am using "lsp-mode" for Javascript, Typescript (including React) and even on a huge Perl repository and I don't find it to be too slow for me. I am running a five year old mediocre laptop using Ubuntu. But perhaps I don't have the same standards as the author of that Emacs fork.

> You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.

Well, it's an impressive feat, for sure. But I don't know anyone actually using that person's fork. So I wonder whether that really is such a huge problem as the author implies.

And -- why do you care anyway since you seem to be happy using VSCode?

I'm not the one you are directly replying to, but I love other aspects of emacs too much to switch (magit, org-mode, macros, code navigation, eshell, etc.) But everything can and should be improved.

> Not only with autocompletion delay to 0.0, but also setting the

> minimum prefix to 1, so that it activates on every keystroke;

> the default is 3.

There, from my config:

  (use-package company
    :after lsp-mode
    :hook (lsp-mode . company-mode)
    :bind
    (:map company-active-map
          ("<tab>" . company-complete-selection))
    (:map lsp-mode-map
          ("<tab>" . company-indent-or-complete-common))
    :custom
    (company-minimum-prefix-length 1)
    (company-idle-delay 0.0))

I had no performance issues whatsoever with it. The suggestions tend to be better in quality when coding in Typescript due to the type hints compared to, say, Perl being designed around dynamic typing. But that's a limitation of the language.

Thanks for pointing out the lsp performance page. I'll definitely be trying all of that today.

If it works, then I wonder why these adjustments are not in default emacs.

> VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable.

"easily verifiable"?!!? This is a ridiculous statement - lots of VSCode responsiveness is dependent on which language servers you're using, and some are definitely faster than others. Sounds like you're extrapolating from the languages that you personally use?

The golang LSP has had widely documented performance problems on large codebases on and off over the past 2ish years (mostly resolved at the moment AFAIK), but it was severe enough that a large percentage of my group at work switched to Goland (Go IDE from Jetbrains) because it was much, much less laggy on our larger projects than VSCode.

Not sure why you are getting downvoted, I think this is exactly the issue I'm seeing.

I didn't downvote this post, but I don't find it hard to see why someone would:

* making incredibly general hand-wavy statements implying vscode is always perfectly lag-free and emacs is terrible

* generally condescending and hostile tone: "if you invested the time.." "you saw fit to reply with"

* some ranting and name-calling about a previous negative experience this person has had, which has nothing to do with anyone in this thread. (given the general tone of this post, i'd say there's a good chance that it was just this person deciding to abuse some unpaid emacs/lsp volunteer/maintainer and they rightfully said "go fuck yourself")

* sadly, there is actually useful information contained in this post, but it's sort of structured as an inverse "shit sandwich" - some ranting and negativity, some useful and relevant information, and then more ranting and name-calling. which, i think, tends to mean most people are just going to ignore it or downvote. not really a constructive contribution to the discussion, despite actually having something useful to say

Yeah, makes sense. Parts of it resonated with me, but it's also a bit too rude.

Similarly you cannot use LSP to query the type of a symbol, something I do all the time in OCaml and other typed languages.

Treesitter will make LSP servers obsolete at some point I believe. The parser framework also comes with query API you can use for semantic analysis of code — it’s about more than just syntax highlighting. Therefore, with treesitter you should be able to do everything what a language server does for you — inside the editor‘s process.

Treesitter knows nothing about your code outside of current file, no? Not to mention all of the project dependencies starting for stdlib.

But a tree sitter mode could parse the related files in the background. That’s exactly what an LSP server does, too.

It's only a parser though, right? So it won't know about derived properties of code like types. I think you still need something like LSP because if the language has type inference, which all modern languages do, you need exactly the same type inference algorithm as the compiler otherwise you'll get incorrect inferences in corner cases.

Most LSP server implementations I've seen are just parsing the source or even stop at just tokenizing it. They don't do anything magical inside the source language (unless a language exposes parsing/compiler internals e.g. like Raku's language server does). So I don't think most LSP servers leverage anything from inside the source language's compiler including performing type inference on your code snippets. Also note: If your code snippet is incomplete because you are just about typing it, this also cannot work in principle. That's exactly why treesitter was invented: To have a robust static parser able to process incomplete or erroneous code.

> if the language has type inference, which all modern languages do

Well, only if your "modern" language is a statically typed language ... And again: Unless your code is correct and complete, you really can not just run "eval" in your source language and obtain type checking out of the box.

Rust-analyzer provides plenty semantics-level functionality, and it deals with incorrect code gracefully.

I am not a Rust dev. It surely looks great.

However, from what I understand it seems to supply just a parser separate from the Rust compiler (https://github.com/rust-lang/rust-analyzer/tree/master/crate...) trying to keep up with Rust‘s development. So, in principle, it could have been just another treesitter parser plugin, too.

So, again, the LSP framework does not directly provide any magical benefit over a static parsing framework. All the semantic analysis capabilities stem from a good parser.

One benefit is that you don’t have to write a complex tree sitter mode for every editor. You can write an LSP server once and plug it into every editor.

Rust analyzer also provides compilation errors, lints, and code actions. It would be a lot of unnecessary work to implement and maintain these functionalities five times in five different editors.

> Treesitter will make LSP servers obsolete at some point I believe.

that seems extremely unlikely, Treesitter is a vibe-based parser framework for syntax highlighting and indentation of single files, LSP is arbitrary language-specific processes doing full-project parsing and analysis and introspection.

> LSP is arbitrary language-specific processes doing full-project parsing and analysis and introspection

No. LSP is a way of separating the job of parsing and static analysis of a source file from the editor and doing it out of process. It's a neat concept for sure moving the burden of implementation from the editor's maintainers over to the language project.

But all language servers really do is performing static parsing and analysis. Some language servers even skip full parsing and just use the plain tokens from the input file (which still works okay for many languages). I suggest people actually take a look into the implementations of various language servers. It is quite disillusioning. When I first heard about LSP I was under the impression it was hooking into the actual language's implementation. But this is really not the case. For example, the deno-based JavaScript language server does not even leverage V8's javascript interpreter but comes with a full re-implementation of a static JavaScript parser written in Rust.

My argument is: You could all have that also using just the treesitter framework because the editor only needs to load the grammar for any language from an external plugin and provide a generic querying API (the treesitter even comes with that and e.g. Emacs just provides Elisp bindings for that AFAIU). The language modes could then leverage the parser to do all the hefty work that currently language servers do but inside the editor's process and, hence, without the overhead of IPC. There is also no single-file limitation. Nothing stops a language mode from parsing include statements and open the corresponding files.

> Also I feel like performance could be improved a lot

Would you mind to share your setup?

I am using „lsp-mode.el“ on a Perl project with >100k LOC (including huge single modules) and never had a problem. I am using cperl-mode together with lsp-mode and Perl::LanguageServer and it works like charm. I also never had an issue with React or TypeScript but in those cases the projects were a lot smaller.

Perhaps you also got an issue with JSON parsing performance. Edit: From someone a couple of threads below: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-...

Reply on news.ycombinator.com