UI suggestion: allow a tab with no more suggestions to fill in "$"
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.