Skip to content
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

Open
dgsuarez opened this issue Sep 17, 2018 · 2 comments
Open

Language Server interface #36

dgsuarez opened this issue Sep 17, 2018 · 2 comments

Comments

@dgsuarez
Copy link
Owner

dgsuarez commented Sep 17, 2018

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.

This was referenced Apr 7, 2019
@dcarral
Copy link
Contributor

dcarral commented Sep 1, 2019

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)

@dgsuarez
Copy link
Owner Author

dgsuarez commented Mar 1, 2020

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:

  • Add a simple filesystem abstraction layer with some simple operations: search files, read / update / create / rename / remove file.
  • Cut a new gem reruby-cli that provides the current CLI, git integration, and implements the FS abstraction from above based directly on disk operations.
  • Cut another gem reruby-solargraph that integrates with the more full featured LSP server, using the in memory data from the server to read / search files, and saving the changes in memory so that they can be sent back to the editor.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants