RMarkdown integration

[meik michalke]

hi,

Am Donnerstag, 19. April 2018, 10:28:23 CEST schrieb Thomas Friedrichsmeier:
> 1) There is the issue of the output file currently being global,
> instead of associated with a workspace (by default). That is clearly
> not the most useful default. We've discussed that earlier, and the
> action plan is essentially clear (and there is a half-finished
> implementation in the work/workspace_output branch).

i got a bit carried away. just brainstorming here.

> 2) There is a separate issue that RKWard could/should provide
> on-the-fly rendering of Rmd files. I think this one is conceptually
> clear as well, although the implementation may not be quite as trivial
> (right now, script windows and HTML windows are two completely separate
> beasts, internally).

yes, i find working with RMarkdown more and more intriguing. we could also use 
the split view feature for this, especially if the HTML file could 
automatically reload on change. but i'd still prefer a full replacement.

> On Thu, 19 Apr 2018 01:35:49 +0200
> meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> > when you think about it, this could potentially replace the
> > additional preview window section we've added to some dialogs,
> > because you could then just toggle the appearance of the code preview
> > section.
> 
> 2b) Regarding this idea, I don't think we'll want to do that: For one
> thing preview will often differ from the "real" thing by e.g. leaving
> out some headers to make better use of screen space, or by limiting
> processing (e.g. to the first n cases) in order to be fast, or by
> making sure not to modify objects in globalenv() (for plugins that
> would otherwise do so).

perhaps it's not something to do for all plugins. for the record, knit() and 
render() have an "envir" argument which i guess could replace the nesting in 
local(), but would of course not help against globalenv() calls. (one could 
mask globalenv() locally for previews, not sure what side effects that might 
have).

> Also note that our previews include non-HTML
> content such as data previews (also plot previews are not technically
> HTML previews, although in theory they _could_ be implemented that way).

i think those should better remain as they are. but since there's already 
alternative preview options, once rendering Rmd is available in RKWard maybe 
it could become yet another option for plugin authors? could be three tabs in 
the preview section: "R" (the code as we currently have it, if produced by the 
plugin), "RMarkdown" (the Rmd code, if produced by the plugin), and "preview" 
(rendered either from R or Rmd, if supported by the plugin). plugins would 
have to declare whether they generate R or Rmd code, and the other tab would 
then become greyed out (if both R and Rmd code would be presented in the same 
tab that would likely confuse users, therefore dedicated tabs signaling what 
is available in which plugin).

> On the other hand, it would be possible to:
> - Move both previews to the same (tabbed/switchable) area, if that seems
>   desirable UI-wise
> - Provide previews by default for all plugins, even if no specialized
>   preview() function is defined. (We need to still make sure to prevent
>   accidental modification of data in previews, though).

see above, masking functions like globalenv() locally in the background could 
be worth a test.

> 3) It may be an interesting idea to make .Rmd a primary output form
> plugins. The immediate advantage is that static elements such as
> headers would be much more readable (in the source, i.e. in the .Rmd,
> compared to .R with rk.print() statements).

definitely. and you could also copy&paste the code as-is into your papers!

> On the other hand, here, I
> am not sure whether this flexible enough to cover all important use
> cases. For intance, sometimes we generate tables with a for()-loop
> iterating over a bunch of objects, and various values displayed in
> columns. Can we reasonably map such use-cases to .Rmd?

if desired, you can completely emulate our current workflow of preprocess(), 
calculate() and printout():

 ```{r setup, include=FALSE}
   # acts like preprocess()
   # prepare the environment
 ```

 ```{r, include=FALSE, echo=FALSE}
   # acts like calculate()
   # does not show up in the output
 ```

 ```{r, echo=FALSE}
   # acts like printout()
   # prints only the results to output 
 ```
 
 ```{r, results='asis'}
   # output formatted tables
   knitr::kable(someObject)
 ```

but it would be much more flexible, because you wouldn't have to follow the 
strictly predefined workflow but could change between calculation and output 
whenever you want. you can also use `r myResult$someCol` for inline code 
(showing only its result) in output text.

> Is the readability advantage large enough to deviate from "plain R"?

i believe the whole structure of the generated code would become much more 
natural, because you'd output results "as you go" and not do all the 
calculations in one section and all the output after that.

> Naively pasting their code into a .Rmd file will mean that it will run each
> time it is rendered, which is asking for trouble, IMO. Can we sort this out
> in a convincing way?

see above, using something like "envir=new.env()" in the rendering functions 
should already solve this issue.

> 4b) Of course, as a much milder variant, we could simply offer an easily
> accessible option "paste to .Rmd file" (or more generically "paste to
> script file"?), wherever exactly we'd fit that into the UI.

what benefit does that have over simple and direct copy&paste, where you can 
also select what you want?

> 5) Finally, there is another theme that is related to, but not
> necessarily identical with R Markdown integration, which is editing /
> updating output after it has been generated. This could come in many
> variants. For instance, we could offer a companion to "Run Again" that
> will replace/update the existing output.

like an "update results" button?

###

for a start, a plain and simple "render Rmd"-button would be awesome.


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  institut f"ur experimentelle psychologie
  abt. f"ur diagnostik und differentielle psychologie
  heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20180419/027b843c/attachment.sig>