[R-SIG-Mac] UI suggestion: allow a tab with no more suggestions to fill in "$"

Timothy Bates tim.bates at ed.ac.uk
Tue May 31 10:12:28 CEST 2016


Hi all,
Simon send code that would essentially allow users to customise the behavior in a very R-ish way. Perhaps someone could even release a package R.app.options to contain functions like this.

Code copied below: I can’t get it to work as add.fn doesn’t exist for me: no doubt soluble, as Simon says it’s loaded as part of the GUI-tools.

While there are a good many things I’d like in the R.app, I realise this is all stuff to create and maintain, so not requesting new preference pane items. So having this as custom code in a package to be launched at  startup would suffice.

re what to do about foo—> when foo$part and foolish both exist. My request was that the tab only do something when the current behavior does nothing. Alternatively, a hierarchial menu would solve this also:

foo$part
     foolish
     tile

A bundle storing options and executing a custom add.fn("rcompgen.completion", function (x)  would allow flexibility over some of these choice.

cheers,
t

> "foo"  and "foolish" in your workspace?
> You want to write  "foo$bar" , but which gets precedence when you enter
> a tab?  "foo$bar" or "foolish” ?

> On 25 May 2016, at 12:51 pm, <cgw at witthoft.com> <cgw at witthoft.com> wrote:
> I have to agree with Simon here that "best guess" will only lead to pain
> in many cases.  
> 
> The best solution, albeit the most painful for Simon :-( , is to have a
> Preferences pane where the user can specify what a tab does, i.e.
> "nothing", " $", "@" , "$first_named_list_item", and so on.   But even
> then, what if there are objects  "foo"  and "foolish" in your workspace?
> You want to write  "foo$bar" , but which gets precedence when you enter
> a tab?  "foo$bar" or "foolish" ?
> 
> [Tim wrote...]
> 1. When a name is already complete, when the user pushes tab again, they
> are expecting ?more? name completion, i.e.,  they want to access a $ or
> @ sub-component. Currently, nothing happens, and the user feels
> ?thwarted?? like the typing ?Simon" but then having to type a space and
> a tab to get "Urbanek" :-)
> 
> 2. Most object components are $ indexed rather than @ indexed), so $ is
> the best guess.

On 24 May 2016, at 10:08 pm, Simon Urbanek <simon.urbanek at r-project.org> wrote:
> That seems like a very strong assumption and my point questioning that assumption. For a lot of objects $ makes no sense which is why I'm reluctant to add $ unconditionally. Really, it only makes sense for lists (and some subclasses) - anything else gets a bit dodgy (it works for some but not others).
> 
> That said, I suppose one possible approach would be to catch any completion that yields just the items itself and if that happens attempt a completion with $ appended and see what it yields. If it yields anything additional, return that result instead. You can test whether you like that by using something like the following:
> 
# add.fn is part of the GUI-tools which are automatically loaded when the R.app GUI starts
# and rcompgen.completion what the GUI uses to call the completion code.

add.fn("rcompgen.completion", function (x) {
 comp <- function(x) {
      utils:::.assignLinebuffer(x)
      utils:::.assignEnd(nchar(x))
      utils:::.guessTokenFromLine()
      utils:::.completeToken()
      utils:::.CompletionEnv[["comps"]]
 }
 res <- unique(comp(x))
 if (nzchar(x) && identical(res, x) && !identical(substr(x, nchar(x), nchar(x) + 1L), "$")) {
    rc <- comp(paste0(x, "$"))
    if (!identical(substr(rc, nchar(rc), nchar(rc) + 1L), "$")) res <- rc
 }
 res
})

# Obviously, you can eve spin that further and carry on with @ if $ doesn't work.


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



More information about the R-SIG-Mac mailing list