Re: Proposal/request for input: slidify export for html slides

[Charles Berry <ccberry@ucsd.edu>]

John Hendy <jw.hendy <at> gmail.com> writes:

> 
> On Fri, Feb 7, 2014 at 11:38 PM, John Hendy <jw.hendy <at> gmail.com> wrote:
> > On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry <ccberry <at> ucsd.edu> wrote:
> 
> [snip]
> 
> > I'll look into those. I just cloned your repo and loaded ox-ravel.
> > Quite nice! It worked /pretty/ well out of the box. One issue is that
> > it doesn't seem to obey :eval no for babel blocks. I exported to .Rmd
> > successfully, but the presentation has a bunch of errors in the code
> > blocks from trying to actually execute the code. The .Rmd doesn't have
> > any instances of ```{r eval=F}; could this feature be added?
> 
> Just kidding. Discovered #+attr_ravel and the proper knitr argument
> for code chunks, which worked as expected with:
> 
> #+attr_ravel: eval=F
> #+begin_src R ...
> 
> I still think it makes sense to allow :eval no. This seems more
> "Org-ish" since the ideology is to have one set of Org syntax where
> possible, which translates to any number of languages. [...]

In principal, it makes sense to map babel header args to knitr chunk 
options. At least when the headers arg and chunk option do about the
same thing.

But there is some effort and overhead involved, so only the most
useful (IMO) have been mapped. Right now, `:noweb yes' will expand the
reference(s) in place before export, and `:exports none' will not export
the block. Maybe one day ...

> I get that we
> have #+attr_latex for latex-only things, #+attr_html for html-only
> things, and so on, but I wouldn't consider :eval to fall into this
> category. Or perhaps I don't understand... would the idea be that I
> don't want to run it in *Org*, but I'd not want all my chunks disabled
> in the .Rmd?

More a matter of what my workflow is (so the issue doesn't arise). I use
the cache=TRUE chunk option on the knitr side to save the results of long
running computations. When I start work, I execute a src block that loads
knitr and knits the *.Rnw (or *.Rmd, etc), which has the side effect of 
loading the cached objects. Then I edit the *.org document. If I am 
working on R code, I run the code interactively either from the src edit
buffer or I C-c C-c the src block. Its handy to leave the results in the
*.org buffer for reference - they get stripped on export. Maybe I edit
a figure caption (knitr option fig.cap=<R character object>), equations,
or text. When I am ready to see the formatted doc, I export via ravel,
knit, and view. The cached objects get rebuilt as needed.

> 
> My workflow might be odd in that I tend to futz with plot parameters
> once, get the desired image, and then set :eval no for the rest of my
> document work so I don't have to wait for plots on iterative exports.
> I try to put all my setup code (load packages, data
> reading/manipulation, etc.) in it's own block so that I can easily run
> that whenever I first open the document. From there I only need to
> re-run a plot block if necessary and I'll just temporarily change
> :eval no -> yes and then back again after execution.
> 

Not odd at all if it saves you time.

But if it takes long to rebuild the objects in that first src block, you
might want to try the cache=TRUE route.


Chuck

p.s. the weird fontification you noted one posting up in this thread seems
like something to raise with the slidify/knitr devs after checking the
*.Rmd to be sure there is no org/ravel induced problem.