3 ms·

I have feelings about the last paragraph there. Most protocols are limiting by nature, so although LSP has made wonders to a lot of languages for a lot of edito

I have feelings about the last paragraph there. Most protocols are limiting by nature, so although LSP has made wonders to a lot of languages for a lot of editors out there; I'm stuck thinking that it might have stifled progress for some as well. I don't have a proposed solution or anything, just pondering if we could have done better.

OtomotO 4y ago
We could always have done better, but the nice thing is, that most of the time, we can. Will it take time and energy? Sure! Such is life. At least it's not as bad as e.g. JavaScript.
rob74 4y ago
Well (Ok, I'm partly contradicting the article here), most of the things LSP supports (autocomplete, jump to definition, ...) have been pretty standard features of more advanced IDEs (the original Visual Studio, the various JetBrains IDEs, even good ol' Delphi) for decades now. So the "problem domain" is pretty well defined already, LSP is just standardizing the interfaces.
- dmitriid 4y ago
  Advanced IDEs are advanced because they provide so much more beyond basic jump to definition and autocomplete (which, again, can be very advanced and be context-aware, provide code shortcuts etc.). It's good that tooling has improved across the board for many languages with LSP, but there's so much more still.
chii 4y ago
> it might have stifled progress for some as well which language got stifled as a result of the existence of LSP? Would that language still have stifled anyway without LSP?
- vim-guru 4y ago
  I haven't looked much into the implementation details of LSP, so I was not aware of custom-commands upon writing my comment. Maybe it hasn't stifled at all, but efforts have definitely been split, as prior art is still maintained years after LSP's launch
Dayshine 4y ago
The protocol also has the concept of custom commands, so whenever I wanted to add some feature that they hadn't thought of I'd just use that. Obviously you have to add custom implementation on the client for each ide, but that's the case without LSP.
- _ZeD_ 4y ago
  cool, so we can have "best viewed with ie" again?
  - jerf 4y ago
    It is unrealistic to expect one server to have everything for every language. What does Haskell do with "extract to method"? What does C++ do with "convert to point-free"? This isn't like HTML where browsers were deliberately fragmented for strategic reasons, languages have these differences for their own good reasons. But sharing as much as possible and harmonizing as much as possible is a huge step forward, even if each language still has a bit around the edges to implement. At least they agree on language, fundamental communication model, common functionality, etc.
    - wtetzner 4y ago
      So when using rust-analyzer with Emacs, I've noticed that it lists code transformation suggestions based on where your cursor is, and you can optionally choose to apply those. That seems to be generic, e.g., rust-analyzer provides the suggestions, and lsp-mode is just listing them. Though I don't know that for sure.

OtomotO 4y ago

We could always have done better, but the nice thing is, that most of the time, we can. Will it take time and energy? Sure! Such is life. At least it's not as bad as e.g. JavaScript.

rob74 4y ago

Well (Ok, I'm partly contradicting the article here), most of the things LSP supports (autocomplete, jump to definition, ...) have been pretty standard features of more advanced IDEs (the original Visual Studio, the various JetBrains IDEs, even good ol' Delphi) for decades now. So the "problem domain" is pretty well defined already, LSP is just standardizing the interfaces.

dmitriid 4y ago
Advanced IDEs are advanced because they provide so much more beyond basic jump to definition and autocomplete (which, again, can be very advanced and be context-aware, provide code shortcuts etc.). It's good that tooling has improved across the board for many languages with LSP, but there's so much more still.

chii 4y ago

> it might have stifled progress for some as well which language got stifled as a result of the existence of LSP? Would that language still have stifled anyway without LSP?

vim-guru 4y ago
I haven't looked much into the implementation details of LSP, so I was not aware of custom-commands upon writing my comment. Maybe it hasn't stifled at all, but efforts have definitely been split, as prior art is still maintained years after LSP's launch

Dayshine 4y ago

The protocol also has the concept of custom commands, so whenever I wanted to add some feature that they hadn't thought of I'd just use that. Obviously you have to add custom implementation on the client for each ide, but that's the case without LSP.

_ZeD_ 4y ago
cool, so we can have "best viewed with ie" again?
- jerf 4y ago
  It is unrealistic to expect one server to have everything for every language. What does Haskell do with "extract to method"? What does C++ do with "convert to point-free"? This isn't like HTML where browsers were deliberately fragmented for strategic reasons, languages have these differences for their own good reasons. But sharing as much as possible and harmonizing as much as possible is a huge step forward, even if each language still has a bit around the edges to implement. At least they agree on language, fundamental communication model, common functionality, etc.
  - wtetzner 4y ago
    So when using rust-analyzer with Emacs, I've noticed that it lists code transformation suggestions based on where your cursor is, and you can optionally choose to apply those. That seems to be generic, e.g., rust-analyzer provides the suggestions, and lsp-mode is just listing them. Though I don't know that for sure.