-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve $
-completion of method-chaining syntax and more
#1469
base: master
Are you sure you want to change the base?
Conversation
$
-completion of method-chaining syntax and more
4b3044d commit adds |
I principally agree with your concern. I will think in practice, it is likely not as problematic. I suggest to add a user option something like "evaluation_level" to control how eager or cautious completion should be. What do you think of that? In any case, parsing is a fast first step before evaluation and could likely replace regex at any desired "evaluation_level". evaluation_level = "super_secure"If opting for this level. The auto-completion must only extract variables and not run user-defined or package defined generic functions. A malicious developer could sneak in bad side effects disguised as variables via e.g. activeBindings or the generic methods # sneaky evaluation #1
makeActiveBinding("xyz", f = \() {print("hello there");42L}, env = .GlobalEnv)
xyz
#> [1] "hello there"
#> [1] 42
# sneaky evaluation #2
l = list()
class(l) = "TomatoCan"
"$.TomatoCan" = \(self, name) {print("hi again");self[[name]]}
l$foo = "bar"
l$foo
#> [1] "hi again"
#> [1] "bar" Created on 2024-01-07 with reprex v2.0.2 evaluation_level = "only_generic_getters"allow (chained) evaluation generic functions like example of what could work: example of what would not work (unless evaluation_level = "only_single_line_scope"There could be a choice which will only parse the same code line to make a meaningful evaluation. evaluation_level = "full_evaluation"Parsing like rstudio, but unlimited evaluation. I will argue if using most package APIs, then there are very few mutable methods out there. The polars and arrow packages is built around immutable structures. Most R objects SEXPs have imuttable behavior, where environment is the central exception. Most R package have APIs where the central objects are imuttable. On top of that polars has lazy evaluation (just as dplyrDB) where evaluation does not trigger computation before explicitly calling There are exceptions e.g. I think some users would happily opt-in for "full_evaluation". |
Thanks for the detailed explanation. I think the evaluation_level should be good enough to handle such problem. |
Update. I have been away for a while. I failed to make good safe list of functions which could be evaluated by IDE auto completion to avoid side effects. In the end, I think this feature is something a user has to willingly opt in to. |
What problem did you solve?
with
setting.json
vscode-R webserver has a simple regex based isolation of code to eval when using the
$
/@
to trigger in-session completion. This regex will fail for many but the simplest cases.Instead I suggest to rely on the R parser and the AST to decide what the left-hand-side of e.g.
$
operator is.This will allow multi-line completion, chained method completion, and potentially anything the R parser accepts.
I'm interested in improving vscode-R similar as this patch for Rstudio completions to support completion for method chaining r-polars (... and also R6 and arrow),
How can I check this pull request?
example 1
example 2
example 3
support r-polars completion ;) (disclaimer I have co-authored the polars bindings for R)
example 4 completion for the arrow package (R6)