From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: Proposal/request for input: slidify export for html slides Date: Sun, 9 Feb 2014 16:26:18 -0600 Message-ID: References: <20140130014552.GA8980@eyeBook> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCcpR-0006y0-Lp for emacs-orgmode@gnu.org; Sun, 09 Feb 2014 17:26:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCcpQ-0005cM-CQ for emacs-orgmode@gnu.org; Sun, 09 Feb 2014 17:26:21 -0500 Received: from mail-oa0-x230.google.com ([2607:f8b0:4003:c02::230]:51702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCcpQ-0005cG-0c for emacs-orgmode@gnu.org; Sun, 09 Feb 2014 17:26:20 -0500 Received: by mail-oa0-f48.google.com with SMTP id l6so6622051oag.21 for ; Sun, 09 Feb 2014 14:26:18 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Charles Berry Cc: emacs-orgmode On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry wrote: >> 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 ... Understood, and no worries. I'm making progress. When you say "expand references," I'm not sure I follow what that means. References = references to variables? So something like :var something=something? > 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=), 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. Ah. I think I follow this. If you knit the exported .org -> Rmd file in the same R session that Org is using, if you change the .org and re-export to .Rmd, knitr is smart enough not to re-run the code? Is that what you mean? That also must imply that export to .Rmd doesn't execute any of the Org babel code, right (otherwise there would be no benefit to your workflow since you'd be waiting for Org anyway)? If that's the case, I think I could roll with that -- I'd just have :eval yes if exporting to .Rmd -> knitr, and do a replace-string to :eval no if I was going to export to Beamer. >> 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. I'm a bit hung up on including non-code-generated images. I'm working through one of my presentations to convert to slidify (and may write up a Worg tutorial or just one on my blog to add to collective knowledge) but am not sure of the right "universal Org syntax" that will work with multiple backends. I'm most used to something like this: #+begin_center #+attr_backend :height {6cm, 400px, etc.} [[./path/to/image.png]] #+end_center That's not seeming to work with ox-ravel thus far. I'd love not to have to change the Org image syntax to straight markdown just for my occasional use of slidify. Thanks again -- you've been immensely helpful in getting me started! John > > > 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. > Will do, but I'm really thinking it's got to be crud that exported from my various latex lines/settings. If things persist after making sure none of that made it through to .Rmd, I'll submit an example file to either knitr or slidify github issues. > >