Interesting code for layout and possible improvements in the script window

[rdstern]

@lloyddewit I include this (possibly these) examples largely for record and information.

I have been running different examples of R-code in the latest merged version. So far, so good.

For information I attach an example where there is a small thing that doesn't seem to run, I also like the layout of the long commands:

This is from the ez package, which is not installed. At this stage I do not wish to install it. It is, however, a package that sounds useful, so it is possible that some R-Instat users may wish to add it themselves. Then they could use the commands through the script window.

a) There is an initial point here, presumably for Chris, that I raised in #7064. It would be a good time for him, or you maybe, to at least check whether it is easy? This would make the installation of extra packages easier for a user. (Currently they have to run as administrator, which is not the same as RStudio.
b) I installed ez and made it an example where I run the code, to see if it works. Here is an example:

library(ez)
#Read in the ANT data (see ?ANT).
data(ANT)
head(ANT)
ezPrecis(ANT)
#Run an ANOVA on the mean correct RT data.
rt_anova <- ezANOVA(
data = ANT[ANT$error==0,]
, dv = rt
, wid = subnum
, within = .(cue,flank)
, between = group
)
#Show the ANOVA and assumption tests.
print(rt_anova)

#Run an ANOVA on the mean correct RT data, ignoring group.
rt_anova2 <- ezANOVA(
data = ANT[ANT$error==0,]
, dv = rt
, wid = subnum
, within = .(cue,flank)
)
#Show the ANOVA and assumption tests.
print(rt_anova2)

1. In his code, I added line 1 for the library(ez)
2. I also changed his equals to <- in 2 of the lines. We already know about that. I am ok even if we don't change that.
3. I was interested in the layout, with the comma at the start of the line. I am still happier that we suggest the commas at the end, but this works fine, because of the initial un-matched bracket. So it is quite a neat layout of the code.
4. However the comments are not echoed to the output window. Please could this be changed? I suggest if there are comments in the code and we choose to run them, then the default (at least) is to copy them to the output window.
5. Then I could not get his print commands to work. It didn't give an error, just didn't print. I can get the results printed, by just not putting the result into an object. But I like the print option here.

[lloyddewit]

@rdstern I don't think any of the points above require changes to the script window. I think points 4 and 5 relate to the clsRLink.RunScript() function.

@ChrisMarsh82 I know that you have also looked at the clsRLink.RunScript() function and believe it needs to be refactored. Do you have any opinions on points 4 and 5 above?

[rdstern]

@lloyddewit oh this is such an interesting response. I was assuming that, because these points start in the script window, then they are to do with you.

Your response, as I understand it, is that because they finish as results in the Output window that it encroaches on someone elses territory!

I add @Patowhiz into this discussion, because he is also handling changes in the output window.

a) To me it is obvious that the default should be for comments in the script window to be echoed in the output window. These comments are, just about, the parallel of the special comments feature in the dialogs. This comments feature in the dialogs was a strong request when we started R-Instat, and I suggest it applies similarly in the provision of scripts in the code.

We could (of course) go a step further. We currently have the option to not put the dialog comments into the output window. So could the same option be applied to these comments too?

b) The print case is different. This is a standard operation on an R object, so the result should go into the output window. I hope that is simple to do.

[Patowhiz]

@lloyddewit I know why about item 4 and 5. We have discussed about why item 5 is happening. My understanding is you are now looking into item 5 in a general way. I'm happy to help if need be.

@rdstern I've explained to @lloyddewit the limitations that we have in regards to the print function.
If we assume it's always a "text" output then we can just capture it's output and send it to the output window. But that's not always the case. For instance, If you call print on a graphical object, the output goes to the R Viewer. If I call print on a html object then the output goes to the browser. Currently we don't yet check to know the "type" of the output of print function in R-Instat "environment". R-Studio somehow knows how to do this.

With the advancements of the R Script library that @lloyddewit is currently working on, there is a possibility that we could check on the properties of the object before print is called, then react to the print function accordingly. I have some ideas on how we could efficiently do this.

Currently, our print alternative is view_object_data function. And you can specify the object format as "text" or other supported visualization formats.

[lloyddewit]

@rdstern I had a good discussion with @Patowhiz yesterday about this. I support his comments above. The only part I'm unsure about is the ability of the RScript library to determine if a particular object should be displayed as text/image etc. I'm not yet sure how we would do this.

I will implement 4 and 5 above (comments displayed and print() implemented). As explained by @Patowhiz above, print() will send graphical output to the R Viewer.

[lloyddewit]

This is just a technical note for myself.
I tested the code above with PR #8494, executing it line-by-line. It did not work because the RScript library failed on the code below. I need to fix this in the library.

[lloyddewit]

This is just a technical note for myself. I tested the code above with PR #8494, executing it line-by-line. It did not work because the RScript library failed on the code below. I need to fix this in the library.

Raised lloyddewit/RScript#18 for this