On Thu, 19 Apr 2018 15:36:38 +0200 meik michalke <[email protected]> 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
pgptrxwn9N258.pgp
Description: OpenPGP digital signature
