languageserver
languageserver copied to clipboard
Roadmap for Language Server
Which language server features are you planning on supporting?
linting / diagnostics are pretty easy, code prettying / formatting somewhat more difficult, although https://github.com/krlmlr/styler is a good step forward there. Robust refactoring and references doesn't really exist AFAIK, although https://github.com/r-lib/pkgapi is a start to mapping function references.
Good question. The fact is there were no plans. It lets me think of the following road map. Some of the items below may lead to developments of new packages.
Short term and easy tasks
- [x] Linting/Diagnostics (basically done)
- [x] Basic auto completion:
- [x] Signature help (hints for function arguments)
- [x] References for objects in default packges
- [x] References for objects in form of
foo::barorxyz:::abc
Medium term
- [x] Formatting:
stylerseems to be a better alternative toformatRwhich is what I had in mind. - [x] Auto completion of attached functions via
libraryandrequire, it requires an inspection the use oflibrary()if it is a script or an inspection ofNAMESPACEfile if it is a package - [x] References of attached functions (similar to auto completion)
- [ ] Code Lens
- [ ] Go to definition
Long term and/or difficult tasks
- [ ] Robust refactoring (code action)
- [ ] Hook into an active R session and do object completions (something nvimcon of Nvim-R).
I think you really need to query the R session to do anything like detecting attached packages. R code can attach packages implicitly if they are in Depends in another package, explicitly in R code with attach() and other ways. Doing so with lexical analysis alone is going to be brittle.
Probably you need something like nvimcom that provides bi-directional communication between the R process and the language server process, this will also let you do object completions easily.
For completions it would also be nice if the package supported custom completions defined using R's rc.options("custom.completer") see ?rc.options for more details. I have a new completeme package that will make it much easier for package authors to define custom completions and have them work in tandem, so while there are few examples today there will likely be more in the near future.
@randy3k What's the benefit in using the language server instead of Hydrogen, which uses the R Jupyter Kernel. In my experience, Hydrogen has auto-completion based on attached packages.
They are different concepts. Language server would be useful in any R files to provide language support. For example, if you are developing an R package, I am quite sure that you don't run Hydrogen on top of the R files. Hydrogen is mainly useful if one is doing data analysis.
I'll read more about the language server protocol, and might be interested in contributing in the future.
@jimhester
It is hard to fully support what RStudio offers via lexical analysis without querying a R session. Inspecting the use of library, the NAMESPACE file and scanning "Depends" iteratively should be sufficient in most cases. The Language server is just a helper anyway, we don't expect it to work under all circumstances.
Discussing something like nvimcom is also too early for now. I also envision such implementation and have put into in the long term target.
Didn't know that there is an option to specify custom completer. Thank for letting me know.
As a Vim user who doesn't use Nvim-R (there are dozens of us!), I can't tell you how much I appreciate your work on this. Having the LSP is an order of magnitude improvement over life before.
A long-term goal could also be supporting Rmarkdown documents. Even the smaller subset of features currently provided by the package would be really handy there too.
Thanks!
You must take care of supporting go to definition.
We appreciate any contributions. If you want to contribute, I am happy to give some guidance.
Do you know if there is any package for providing go to definition? Or you can do manually that by searching the workspace and choosing the one that matches the definition in the syntax.
We will need to manually search for the definitions and apply the match. That's one of the reasons why I still haven't implemented it.
Something else I want to ask you about. Have you implemented yet symbol outlining??