RMarkdown integration

[Thomas Friedrichsmeier]

On Thu, 19 Apr 2018 15:36:38 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> i got a bit carried away. just brainstorming here.

Yes, so keep the idea flowing.
 
> > 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).

Well, note that there's also .GlobalEnv and <<- to worry about. And
then plugins could create or modify files, modify files in
environments that are somewhere in, but not identical to globalenv(),
change the working directory, set options...

> once rendering Rmd is available
> in RKWard maybe it could become yet another option for plugin
> authors?

Yes, we can always go the "more options"-route, but that's also going
to add complexity (both in implementation _and_ usage), so I'm trying
to understand
- just how much would we gain by _adding_ .Rmd at this point
- could we reasonable go .Rmd all the way, here?

> 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.

Well, actually, the predefined workflow is simply a convention for
consistency. (Ok, there were some long obsolete historical reasons for
this. But also some more thoughts behind this, esp. the idea that one
day we might want to allow to "chain" plugins (simple example: First
apply a filter, then do some test). In that case it may or may not make
sense to skip over the printout() of earlier steps. This is not the
only way to do that, but well, the other idea was to have a predictable
code layout.)

Actually, a plugin _could_ absolutely have all its code in
preprocess(), and it would not make a practical difference. So,
actually, we could think about loosening this separation, entirely
independently of .Rmd.
 
> > 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?

One-click(TM).

> > 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?

Yes.

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

Well, I'll think about how to implement that.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20180419/c439f7b9/attachment.sig>