Extensions to R / RStudio's autocompletion system

[jimhester]

trafficstars

This was proposed by @kevinushey for last year's unconf, but he unfortunately Kevin had to miss the event last year. (https://github.com/ropensci/unconf17/issues/52)

In the meantime I have started a proof of concept package https://github.com/jimhester/completeme, that implements some of what he proposed, but it would be great to improve the RStudio IDE integration and discuss ways to make this more full featured and robust, both for terminal completions, things like https://github.com/REditorSupport/languageserver and in the IDE.

[jennybc]

I'd love to see this, as you well know @jimhester. readxl was an early target of your explorations (unmerged PR: https://github.com/tidyverse/readxl/pull/320).

For context, this would be a nice way to expose, say, a set of example inputs in a package. In the world of readr and readxl, you could make it easy for users to get the possible filenames in front of their eyeballs and then pick one.

While I'm wishing ... it would be interesting to see if the developer interface could be more like match.arg(), i.e. your wishes about auto-completion are expressed in the target function itself vs. elsewhere in the package.

[maurolepore]

I thought it was me. But I learned I wasn't alone when I saw @jimhester live-coding at rconf2018 -- struggling with autocompletion :)

[ajwtech]

I have been doing a bunch of work on https://github.com/jimhester/completeme under ajwtech/completeme. More on that below. but I am at a point where I am trying to figure out how to pass a response back from a custom completer so that the Rstudio completion engine will take over and apply the correct type and prefrences to it such as prefs.insertParensAfterFunctionCompletion() currently anything returned from a custom completer will just appear to be a variable name in the popup list. I have been exploring rstudioapi:::toolsEnv() trying to find a way to pass control back. Anyone have any suggestions for this?

------- Info on what I have been doing on completeme My recent PR has drastically changed how it handles initially returning information about so it now gives the developer the arguments and defaults for whatever is in the environment linebuffer. it also exposes the R "normalCompletions()" function from utils.

In my use case I needed to access a previously typed argument in order to connect to an odata connection to list objects in a lab system that a user could code against.

[ajwtech]

I may have just answered my own question. I need to add the type to match the types in rstudioapi. like attributes(env$comps) <- list(class = "completions", type = attr(env$comps, "type") %||% 15)

^^^ doesn't seem to be working...

[bedantaguru]

Is this somehow linked with topics mentioned in help("rcompgen")

[ajwtech]

This is linked with the rc.options() topic. essentially the package uses the custom.completer option to create a custom completer function. The package then allows you to register additional completers through the one created.

[bedantaguru]

Thanks that sounds great.. any plans for putting this in CRAN

[bedantaguru]

Eventually, I could create a hackish way to do it.

Here is what you need: r-rudra/patch Specifically, here is the file responsible for these things.

@kevinushey thanks for such a nice documented file.

Here is what I tried.

• It can auto-complete future::plan
• dplyr::filter unique cases (like iris %>% filter(Species == <TAB>))
• match.arg type arguments in user defined or any functions (like cor(method = <TAB>))