RMarkdown integration

[Thomas Friedrichsmeier]

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 <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). 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
-------------- 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/5e13b30f/attachment.sig>