Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language.

While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST.

So LSP actually leads to more duplicated code and worse editors.

VS Code will never be able to match the functionality of IDEA unless each language server reimplements all the functionality slightly differently. What a mess.

I'm implementing an LSP server using IDEA as a backend, so hopefully VS Code will be able to match the functionality sometime.

https://github.com/Ruin0x11/intellij-lsp-server

That being said, as an implementor I'm finding cases where LSP's feature set is underdeveloped. For example, there is nothing in the spec to account for renaming files, so I can't put in my rename action without the behavior being incorrect (because if you rename a class in Java you have to rename the corresponding file, which IDEA handles). Also some things require custom LSP requests, like getting the list of build configurations to run. I think this is a product of the Java support in IDEA being so much more comprehensive than anything in LSP so far. But hopefully as the spec is improved these issues will be worked out

And no other editor can implement IDEA’s feature set except from scratch. What a mess.

Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.

LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specifi...

Is your complaint that they're not iterating fast enough? Because this is something I'd prefer they take their time and get it right, especially once we get past the low-hanging fruit and into complex things like debugging.

My complaint is that the entire concept on which LSPs are based today — each LSP reimplements all functionality itself, the editor is only a dumb textview — is wrong.

Language servers should expose an AST, not some actions. Language Servers shouldn't even know where the cursor is — or how many there are.

With a proper LSP, you can also write a linter just by using the protocol, you can call the same action on a thousand places at the same time, and the refactoring functionality is implemented only once, and reused everywhere.

The entire design of LSP is flawed.

Can you go into more detail please on why it had to be subpar?

LSP supports refactorings via Code Action Request messages.

You mean, with common IDE plugins, you end up with one implementation of refactoring functionality per IDE. That's what's being avoided here (because, for one thing, there are far more IDEs than you think, and they don't deserve to be second-class citizens.)

No, all IDEs could use the same AST backend.

Just like LSP. Just a more intelligent protocol.

You have one implementation of refactoring, instead of, as today, one per language.

Technically solvable if somebody writes a LSP proxy server that merges together backends.

Oh, you're right. We should just dump all other editors and use IDEA. /s

Or maybe we should build an LSP that exposes an AST in a way that is more useful to IDEs, like IDEAs plugins do today.

In fact, the code in IDEA that does this is open source, so you can start with it, and build a better LSP based on it.

This would be an interesting idea, provided that editors go all-in on supporting such refactoring logic on the client side. The IDEA code defines "extension points" so language specific support for common actions can be implemented in a modular fashion. When the user decides to execute a refactoring, it is just the matter of iterating through the loaded extension points and choosing the one for the language being edited. Having worked with the IDEA code myself to build an LSP server, there end up being language-specific parts such that the support between e.g. Java and Kotlin have to be handled separately. However that was probably due to the way I wrote the server; these could be generalized to a single "refactor" entrypoint with some work. It's just that using the current LSP model with the server being the part with AST awareness, there isn't much gain in doing so.