Recognize symbols created by delayedAssign / assign / makeActiveBinding

[shrektan]

Closes #362

A simple test file

x <- 1
y <- "a"
z <- function() {
  'hello'
}
delayedAssign("d1", 1)
delayedAssign(value = function() 2, x = "d2")
base::delayedAssign(value = "3", "d3")
var <- "d4"
delayedAssign(var, 4)
delayedAssign(("d5"), var)

makeActiveBinding("a1", function() 1, environment())
makeActiveBinding(function() "2", sym = "a2")
base::makeActiveBinding(fun = function() stop("3"), sym = "a3")
makeActiveBinding(("a4"), function() 1, environment())

assign(value = "1", "assign1")

Outline can display the promise / active binding symbols now

[renkun-ken]

It does not seem to work with the following:

makeActiveBinding(("a"), function() 1, environment())

We could simply ignore these calls with the name being not simply a string literal.

[renkun-ken]

I just recall the reason we didn't detect these assign functions. Consider the following examples:

e <- new.env()
assign("var", 1, e)
assign("var", 2, globalenv())
assign("var", 3, .GlobalEnv)

All these assign functions have an argument to specify which environment the assignment should be done. The document outline only lists the global symbols in the document. However, these assignments may be done in any environment. Should we detect the pos or envir argument?

[shrektan]

Yes, I'm aware of this issue. My personal points are:

1. The outlined symbols are not necessarily "global" - as the script may be used in an R package or be source() with local=TRUE. So maybe we should call them as "top-level" symbols.
2. Except assign(), I guess in majority cases, users use delayedAssign() or makeActiveBinding() on the top level to make "top-level" variables.
3. "Greedy" may be a good choice for the document outline purpose.

Simple improvements for this, in my opinion, could be detecting the pos / envir / assign.env argument and only mark the symbols as top-level, when these arguments:

• are not provided, or
• are provided and equal to default (-1 / parent.frame(1)) or .GlobalEnv, etc...

However, I'm hesitate to do it as it complicates the code and it's difficult to consider all those possibilities.

So my suggestion is that we may choose one of the two strategy:

1. Greedy strategy: Ignore the possibility that those symbols may be assigned in a different context, for the time being. We can improve this when users complain that this causes trouble.
2. Detecting those assigning environment arguments but using a simple strategy. That is we may assume that if those args are provided, it means users want to assign the symbols to a different environment - so we don't display them in the outline. In short, we ignore those symbols whose assigning env arguments (e.g., pos or env) are provided.

What do you think?

[renkun-ken]

Detecting those assigning environment arguments but using a simple strategy. That is we may assume that if those args are provided, it means users want to assign the symbols to a different environment - so we don't display them in the outline. In short, we ignore those symbols whose assigning env arguments (e.g., pos or env) are provided.

I think this is good enough for most cases.

[shrektan]

As makeActiveBinding() doesn't have a default env, I need to check the env agains a list of possible "top-level" candidates. Thus, the checks for assign() and delayedAssign() are added in the meantime.

[renkun-ken]

LGTM