-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language Server interface #36
Comments
For what it's worth: it seems like https://github.com/castwide/solargraph is the most mature Ruby option at the moment (funny enough, this has been recently asked @ Reddit: https://www.reddit.com/r/ruby/comments/cwpype/best_ruby_lsp_server/) However, https://sorbet.org/ has been recently open-sourced (!), and it seems to come with an internal Ruby language server. (see castwide/solargraph#194) |
Some thoughts on this (yearly update? 😂). From my (limited) research, LSPs are not "combinable". You set up an LSP per language and your editor uses that. So a reruby LSP would prevent you from using others like Solargraph. Another point is that LSP operations (like renames) are not expected to work on files directly, but to work based on workspace edits that the editor then applies. This is not how reruby currently operates, it performs changes directly on disk. On a similar note, we search directly on disk, so changes not yet saved in the editor will not be affected by reruby changes, which again is suboptimal. So my current idea is to do something like:
I also think that having the FS abstraction will make integration tests easier to implement, which is nice since right now we are lacking in that front. |
LSP is a much better option to integrate with editors than doing a plugin for each. As such, this would deprecate #3, and the existing reruby.vim
Further research is required, but it looks like the editor needs to receive changes to be made in the workspace, and we perform them ourselves. This should not be that big a deal, and would also allow for easier testing. However, for a POC, maybe we can work around it by performing the changes ourselves and returning no changes to the client.
The text was updated successfully, but these errors were encountered: