RMarkdown integration

[meik michalke]

hi,

Am Freitag, 11. Mai 2018, 21:21:46 CEST schrieb Thomas Friedrichsmeier:
> Ok, I've finally made a start on this (branch work/render_rmd).

after that, we can rename RKWard into aRsome :-D

unfortunately, i couldn't check it out yet, too many projects ATM.

> What I have done so far is a toolbar button / checkable action
> "Run->Render Preview". This will show a live preview (updated as you
> type) side by side with the .Rmd, inside the same window. I went for
> that instead of a split window, as it would seem to accomplish roughly
> the same, with less potential for confusion (by keeping source, and
> rendered view next to each other).

sounds good. but wouldn't it be more useful to have split windows to be able 
to move the preview to a second screen?

> 0) This uses knit2html, for now, i.e. v1, only. This will be easy
> enough to change, but I really have no idea on what to settle on.
> Should be an option that users will be somewhat likely to have
> installed, already, and that "just works" for most real-world usecases.
> So which option is that?

i'd assume that most people use v2 nowadays, because RStudio defaults to it.

it would be best to support both v1 and v2 because they are partly 
imcompatible and it would also be confusing if only a fraction of your 
documents is supported.

in RStudio you can add "<!-- rmarkdown v1 -->" to your source file to force 
the use of v1. that's a policy we could adopt, so there's no need for further 
configuration or complicated rendering options.

> 1) Now, the first thing missing would seem to be a "final" rendering
> option in addition to the preview. Probably with choice of output
> format, and relevant options. Sounds like something to be handled in a
> plugin?

yes, sounds like it.

> 2) Render Preview really only makes sense for .Rmd files, but for the
> moment it's shown for all scripts. I could hide the action based on
> file-name extension, of course. But what is the relation to the other
> "Run" actions? I suppose "Run selection" and "Run line" still make
> sense in an .Rmd context.

yes.

> But probably not "Run all". So "Run all" and "Render Preview" would actually
> be "swapped" depending on the type of script file?

sounds reasonable to me.

> 3) But actually, why limit "Render Preview" to .Rmd, when knitr also
> "does" LaTeX, HTML and others? Would it seem "safe" to assume that
> "Render Preview" is relevant for any file that is not a plain R script?
> The most versatile option in this direction would indeed seems to be
> pandoc, but then, is there a acceptable fool-proof way of installing
> pandoc from R?

RMarkdown v2 depends on pandoc anyway, so if we'll support v2 then we can 
assume that as a given (and the debian package dependencies should have it 
added).

on rendering more MIME types: good idea as long as there's an obvious relation 
to R in the context of RKWard, e.g., rendering LaTeX in the form of SWeave 
documents sounds reasonable to me. for normal LaTeX documents we should not 
risk to make people assume RKWard wants to act as a proper LaTeX editor like 
kile.

an option to render .Rd documentation would be neat for package authors, using 
tools::Rd2HTML().

> 4) But further: The new preview shares a lot of code with our existing
> plugin previews. This also means that - in principle - it would not be
> too hard at all to provide various types of previews (data, plots,
> HTML) for regular R scripts (and at least for HTML aka "RKWard Output"
> it would seem relatively straight-forward). So instead of limiting
> "Render Preview" to .Rmd files, perhaps we really want to generalize it,
> instead? But how exactly (UI-wise)?

that would lead a way to having one output file per script. i like the idea.
can we also merge this view with the plot device, somehow? instead of split 
document, RKWard could get a designated preview section with tabs.


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/20180529/509640b0/attachment.sig>