5 ms·

I had high hopes that JetBrains would relent on their decision to avoid implementing a Language Server Protocol server. There is a 3rd party implementation out

I had high hopes that JetBrains would relent on their decision to avoid implementing a Language Server Protocol server. There is a 3rd party implementation out there, but it needs a lot of help. I realize this cuts into their core business... but it'd sure make using Vim to write Kotlin a more pleasant experience.

tasubotadas 4y ago
Never seen language server come even close to what intellij offers.
- iudqnolq 4y ago
  When I last used them for Rust about two years ago they were racing neck and neck against a language server being refactored to share a backend with the reference compiler. I switched to the language server because I felt running the actual compiler will in the long term always work better than writing your own parser. I was on the Jetbrains student discount, so I made a small recurring contribution to the rust language server project. I think in retrospect that was the correct decision. The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
  - dmitriid 4y ago
    > running the actual compiler will in the long term always work better than writing your own parser. No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc. > The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros. None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
    - mdaniel 4y ago
      I once heard that an editor spends the majority of its time in an error state, and only periodically someone stops typing in hopefully(!) a valid state. Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work
      - dmitriid 4y ago
        > Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
    - iudqnolq 4y ago
      > No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. That's the conventional wisdom. The rust team's theory was that they could make it work. They did. > As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc. Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought? > None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server. That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
      - dmitriid 4y ago
        > That's the conventional wisdom. The rust team's theory was that they could make it work. They did. They didn't. Does the rust compiler support continuous analysis required by an IDE? > That's not the case for rust. Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
- nobleach 4y ago
  While that's absolutely true, I'd be totally fine with what an LSP _does_ offer. Auto imports, go to definition, list usages, etc. I don't need the heavy refactoring tools.

tasubotadas 4y ago

Never seen language server come even close to what intellij offers.

iudqnolq 4y ago
When I last used them for Rust about two years ago they were racing neck and neck against a language server being refactored to share a backend with the reference compiler. I switched to the language server because I felt running the actual compiler will in the long term always work better than writing your own parser. I was on the Jetbrains student discount, so I made a small recurring contribution to the rust language server project. I think in retrospect that was the correct decision. The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros.
- dmitriid 4y ago
  > running the actual compiler will in the long term always work better than writing your own parser. No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc. > The language server team has done great work, and they support things impractical to do with just parsing like autocompleting functions defined by macros. None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server.
  - mdaniel 4y ago
    I once heard that an editor spends the majority of its time in an error state, and only periodically someone stops typing in hopefully(!) a valid state. Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work
    - dmitriid 4y ago
      > Thinking how to generate helpful recovery states in an ide's parser sounds like an incredible amount of work It is. Error recovery is one of the biggest issues precisely for the reason you mentioned :)
  - iudqnolq 4y ago
    > No, it won't. A compiler and an IDE code analyzer have completely different non-intersecting goals. That's the conventional wisdom. The rust team's theory was that they could make it work. They did. > As an example, consider error recovery. Where a compiler can just fail with an error, in an IDE you need to continue to provide full correct syntax highlighting, display all other potential errors and warnings, continue providing code analysis (including suggestions on how to fix the error) etc. Possibly the Rust compiler's unusual prioritization of friendly error messages with helpful suggestions meant this wasn't as big a difference as you thought? > None of these are provided by the language server team. These are provided by whoever wrote the code to analyze your stuff and provide data to the language server. That's how it works for many languages: the language server implementation is a thin wrapper around an existing tool. That's not the case for rust. I've watched the work the Rust language server team did on their language server implementation and the compiler. It was impressive.
    - dmitriid 4y ago
      > That's the conventional wisdom. The rust team's theory was that they could make it work. They did. They didn't. Does the rust compiler support continuous analysis required by an IDE? > That's not the case for rust. Funny. Rust analyzer blog would have us believe that they have their own parser and analyzer.
nobleach 4y ago
While that's absolutely true, I'd be totally fine with what an LSP _does_ offer. Auto imports, go to definition, list usages, etc. I don't need the heavy refactoring tools.