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

Roadmap for Language Server #1

Open
jimhester opened this issue Sep 13, 2017 · 12 comments
Open

Roadmap for Language Server #1

jimhester opened this issue Sep 13, 2017 · 12 comments

Comments

@jimhester
Copy link

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.

@randy3k
Copy link
Member

randy3k commented Sep 13, 2017

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

  • Linting/Diagnostics (basically done)
  • Basic auto completion:
  • Signature help (hints for function arguments)
  • References for objects in default packges
  • References for objects in form of foo::bar or xyz:::abc

Medium term

  • Formatting: styler seems to be a better alternative to formatR which is what I had in mind.
  • 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
  • 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).

@jimhester
Copy link
Author

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.

@kylebarron
Copy link

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

@randy3k
Copy link
Member

randy3k commented Sep 13, 2017

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.

@kylebarron
Copy link

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

@randy3k randy3k changed the title Goals for the language server? Roadmap for Language Server Sep 13, 2017
@randy3k
Copy link
Member

randy3k commented Sep 14, 2017

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

@michaelquinn32
Copy link

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!

@minkir014
Copy link

You must take care of supporting go to definition.

@randy3k
Copy link
Member

randy3k commented May 24, 2019

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

@minkir014
Copy link

minkir014 commented May 24, 2019

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.

@randy3k
Copy link
Member

randy3k commented May 24, 2019

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.

@minkir014
Copy link

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

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

5 participants