Are there any plans regarding first class support for LSP (or, more generally and perhaps more useful, first class support for extensions providing semantic knowledge about the code)?
I know that LSP plugin exists, but, anecdotally, folks are having trouble with it. Which i think is understandable https://lsp.sublimetext.io/features/ says Show Code Actions: UNBOUND, and this is the second most useful thing in LSP (the first is extend selection), it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.
Just wanted to share my thoughts on why LSP as an open source plugin has more benefits than getting first class support from ST devs.
Cons of getting first class support from ST:
- ST is closed source. That would mean that the LSP source code would be closed source too and that would not allow other people to contribute to it.
- Implementing the LSP client in c++ won't make the user experience faster.
The speed mostly depends on the speed a language server returns a response to the LSP client.
- ST devs would shift focus on implementing the LSP spec which is mainly driven by Microsoft and the spec is somewhat driven by VS Code functionality. So ST would chase after offering the same functionality as VS Code, but then always be a step back.
Having LSP as a plugin allows the best for both ST users and ST devs.
It allows ST users to contribute to the LSP plugin, while ST devs can focus on making ST more awesome on their own way and adding new API-s.
All I can say is that LSP already has first class support, because the ST devs have specifically expanded the API to allow LSP to implement certain features. :)
Yeah, this is crucial to me. I was formerly a paid user of ST3 before switching to VSCode, but gave the ST4 beta a try a month or so ago. I couldn't get the LSP to work for me for Elixir, so I ended up back on VSCode for now.
I figured I'd wait until the non beta release, and try again.
The sort of minimal deal breaker level of support for me is being able to jump to definition. The symbols, if I understand correctly, are based on the syntax configuration, and for the common Elixir one, it includes the type definition line, each function head, and the callsites of the function, which makes it nearly useless for symbol navigation.
I figured LSP would help in this regard, but I couldn't make it work. The docs were vague, and I think I had to put some JSON configuration structure in some file, but nothing I tried I guess was the right file or right structure.
Still, I love everything else about Sublime and am excited now for multi-tab-select, so I'll probably give it one more try. Hopefully LSP is better integrated or documented by now.
I didn't have much to do with LSP or the plugins during development, but from what I've heard most of the work has already been done. LSP has had a ST4-specific branch for quite some time.
Let me also give an insight why keybindings are UNBOUND :)
Each person has different criteria of what is important,
Some people like code actions, some think it is the goto definition command, but almost all keybinding in LSP are UNBOUND. The main reason is to not cause conflicts with default keybindings.
Here is an example for code actions. Most editors use `ctrl+.` to trigger code actions,
but `ctrl+.` is a default ST keybinding used to go to the next modification in the code.
A lot of people consider it bad if a plugin overrides default keybindings,
so LSP lets the user decide what keybinding to assign to LSP commands.
I know that LSP plugin exists, but, anecdotally, folks are having trouble with it. Which i think is understandable https://lsp.sublimetext.io/features/ says Show Code Actions: UNBOUND, and this is the second most useful thing in LSP (the first is extend selection), it’s not that the plugin is wrong: it’s just that you can do only so much if the editor lacks first class UI/UX concepts for features, required to expose LSP to the user.