Extensions to R / RStudio's autocompletion system

[kevinushey]

It would be handy to allow packages to register their own autocompletion routines for certain functions. A simple example might be shiny::runExample() -- users might write

shiny::runExample(<TAB>)

The autocompletion system could then provide the set of available examples as autocompletion candidates.

[gaborcsardi]

@kevinushey yeah, that would be nice.

[jimhester]

Definitely think this could be useful, I experimented a little with this for base R's completion at https://github.com/tidyverse/readxl/pull/320/files.

People completions independently won't work well because you can only define one custom completion function at a time. But a completion package package authors can use to register completion functions and will handle the fallbacks for you will work well.

We also need a way to hook into RStudio's completion machinery and provide helper functions to make registration of completion functions easier.

[hadley]

Ideally we'd have some way to take advantage of the file autocomplete, but with some function that filter the list of files.

[kevinushey]

Here's the infrastructure I'm imagining:

We could develop an R package (call it autocomp or something similar), and it would be responsible for maintaining a set of autocompletion functions, as registered by other users / packages.

Suppose we wanted to register an autocompleter for shiny::runExample(). We could do this with an interface like:

# imagine this living in a package's .onLoad or similar
autocomp::register_completer("shiny::runExample", "example", function(token) {
  examples <- list.files(system.file("examples", package = "shiny"))
  types <- rep(autocomp::completion_types$FILE, length(examples))
  autocomp::completions(examples, types)
})

The first argument is used to define the package + function name; the second the argument for which this completer should be registered, the third the actual completion function (which should return a set of completion results).

The 'token' object would simply be the R code lying before the user's cursor; we can think about what other context might need to be stuffed in there.

The R package could register its top-level own custom completer (ie, by defining rc.options("custom.completer"), to ensure that registered completers work in plain-old R sessions, while hosting environments (e.g. RStudio) could do its own work to override + use an autocomp-registered completion engine.

[jennybc]

Application numero uno: autocompleting username/repo in install_github() from some reasonable set of options.

[gaborcsardi]

@jennybc from your history.

[jimhester]

Jenny, just use https://github.com/jimhester/autoinst :stuck_out_tongue_winking_eye:

[gaborcsardi]

@jimhester it must be magical if it knows what I am about to install from GitHub. :)

[jimhester]

Well the lookup has to error first, but it uses http://rpkg.gepuro.net/ to figure out GitHub packages, which is clearly not perfect, but it works pretty well.

[bedantaguru]

Check my comment on https://github.com/ropensci/unconf18/issues/65#issuecomment-723088752

Keeping this in case anyone is interested in this matter.

Just a prototype which is doing following things

• 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>))

It can be extended to any custom packages/ functions I guess.