7 ms·

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 ca

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.

kuschku 8y ago
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.
- girvo 8y ago
  And no other editor can implement IDEA’s feature set except from scratch. What a mess.
  - kuschku 8y ago
    Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.
    - Analemma_ 8y ago
      LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specification#version_3_7_0 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.
      - kuschku 8y ago
        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.
- pjmlp 8y ago
  LSP supports refactorings via Code Action Request messages.
- icholy 8y ago
  Oh, you're right. We should just dump all other editors and use IDEA. /s
  - kuschku 8y ago
    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.
    - nonbirithm 8y ago
      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.
- azinman2 8y ago
  Can you go into more detail please on why it had to be subpar?
- verroq 8y ago
  Technically solvable if somebody writes a LSP proxy server that merges together backends.
- nonbirithm 8y ago
  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 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.
- nonbirithm 8y ago
  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 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
- derefr 8y ago
  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.)
  - kuschku 8y ago
    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.

kuschku 8y ago

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.

girvo 8y ago
And no other editor can implement IDEA’s feature set except from scratch. What a mess.
- kuschku 8y ago
  Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.
  - Analemma_ 8y ago
    LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specification#version_3_7_0 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.
    - kuschku 8y ago
      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.
pjmlp 8y ago
LSP supports refactorings via Code Action Request messages.
icholy 8y ago
Oh, you're right. We should just dump all other editors and use IDEA. /s
- kuschku 8y ago
  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.
  - nonbirithm 8y ago
    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.
azinman2 8y ago
Can you go into more detail please on why it had to be subpar?
verroq 8y ago
Technically solvable if somebody writes a LSP proxy server that merges together backends.
nonbirithm 8y ago
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 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.
nonbirithm 8y ago
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 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
derefr 8y ago
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.)
- kuschku 8y ago
  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.