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, <c...@witthoft.com> <c...@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.urba...@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.
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
