languageserver icon indicating copy to clipboard operation
languageserver copied to clipboard

Roadmap for Language Server

Open jimhester opened this issue 8 years ago • 12 comments

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.

jimhester avatar Sep 13 '17 11:09 jimhester

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::bar or xyz:::abc

Medium term

  • [x] Formatting: styler seems to be a better alternative to formatR which is what I had in mind.
  • [x] Auto completion of attached functions via library and require, it requires an inspection the use of library() if it is a script or an inspection of NAMESPACE file 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).

randy3k avatar Sep 13 '17 13:09 randy3k

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.

jimhester avatar Sep 13 '17 14:09 jimhester

@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.

kylebarron avatar Sep 13 '17 15:09 kylebarron

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.

randy3k avatar Sep 13 '17 15:09 randy3k

I'll read more about the language server protocol, and might be interested in contributing in the future.

kylebarron avatar Sep 13 '17 15:09 kylebarron

@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.

randy3k avatar Sep 14 '17 00:09 randy3k

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!

michaelquinn32 avatar Feb 28 '18 00:02 michaelquinn32

You must take care of supporting go to definition.

minkir014 avatar May 24 '19 12:05 minkir014

We appreciate any contributions. If you want to contribute, I am happy to give some guidance.

randy3k avatar May 24 '19 13:05 randy3k

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.

minkir014 avatar May 24 '19 13:05 minkir014

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.

randy3k avatar May 24 '19 16:05 randy3k

Something else I want to ask you about. Have you implemented yet symbol outlining??

minkir014 avatar May 24 '19 17:05 minkir014