Hi! Interesting thoughts. I'll try to split into a few different areas, starting with the easier ones:
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). 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). On Thu, 19 Apr 2018 01:35:49 +0200 meik michalke <[email protected]> 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). 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). 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). 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). 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? Is the readability advantage large enough to deviate from "plain R"? 4) Another idea would be to make .Rmd the (intermediate) output format. Essentially, plugin generated code would simply be pasted into a .Rmd file (which the user can simply edit in any way), and then this will be rendered into HTML (or another final format), automatically. This idea has a lot of charm, but there are also some difficulties. For instance, again, there are some plugins that will modify objects (filter / sort / generate / import, but also some plugins that save the result of calculations), or more generally speaking plugins that "have side-effects". So far we can rely on their code being run _exactly_ once, and at an unsurprising point of time. 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? 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. 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. This could even be taken as far as an option to "regenerate" an entire output file. It should be noted, however, that this will again lead up to essentially the same set of problems as listed for 4), except for being a bit more manual. -- So far for my attempt at partitioning the problem. Regards Thomas
pgpoObo45UQNw.pgp
Description: OpenPGP digital signature
