Proposal/request for input: slidify export for html slides

Proposal/request for input: slidify export for html slides

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Greetings,


I use R quite a bit, and ran into a new exporter sometime last year called
Slidify:
- http://slidify.org/start.html

Would anyone be able to suggest a good starting place for creating a
possible backend exporter for this? RStudio allows this pretty easily, but
I really like my prose/code in Orgmode format and working within Emacs.
Plus, it allows the obvious benefit of exporting to Beamer or Slidify at
will (perhaps with some tweaks).

I planned to look at the existing non-Beamer libraries for reference, but
thought it wouldn't hurt to inquire about potential pitfalls based in how
Slidify works:
- initializes a git repo with some css/other folders
- creates an index.Rmd file (markdown, which one edits to create
presentation)
- spits out an index.html file when you run `slidify("index.Rmd")`

I think the folders in the presentation directory could be initialized and
then Org syntax could be converted to R markdown, followed by running the
slidify command to compile, but am not sure.

I'm coming from ~zero elisp experience but think this would be a neat hobby
project if I could pull it off.


Thanks for any input,
John

[-- Attachment #2: Type: text/html, Size: 1463 bytes --]

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

[Ahmadou Dicko]

[-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --]

I love slidify too and I think that having similar functionnality in org
could be great.
I think that you have everything to do that using the html backend, you
just need to interface the right Javascript/HTML5 library.
In slidify you can use io2012, deck.js, shower and landslide and I know
that you can use deck.js through ox-deck and it will not be difficult to
create and interface for other library too.
For example if you need a nice non Beamer library you can also check
ox-reveal <https://github.com/yjwen/org-reveal/> which interface reveal.js.

Here is a minimal example with R code.  (Make sure to have ox-reveal.el in
your path and export using C-c C-e R R)




On Thu, Jan 30, 2014 at 12:05 AM, John Hendy <jw.hendy@gmail.com> wrote:

> Greetings,
>
>
> I use R quite a bit, and ran into a new exporter sometime last year called
> Slidify:
> - http://slidify.org/start.html
>
> Would anyone be able to suggest a good starting place for creating a
> possible backend exporter for this? RStudio allows this pretty easily, but
> I really like my prose/code in Orgmode format and working within Emacs.
> Plus, it allows the obvious benefit of exporting to Beamer or Slidify at
> will (perhaps with some tweaks).
>
> I planned to look at the existing non-Beamer libraries for reference, but
> thought it wouldn't hurt to inquire about potential pitfalls based in how
> Slidify works:
> - initializes a git repo with some css/other folders
> - creates an index.Rmd file (markdown, which one edits to create
> presentation)
> - spits out an index.html file when you run `slidify("index.Rmd")`
>
> I think the folders in the presentation directory could be initialized and
> then Org syntax could be converted to R markdown, followed by running the
> slidify command to compile, but am not sure.
>
> I'm coming from ~zero elisp experience but think this would be a neat
> hobby project if I could pull it off.
>
>
> Thanks for any input,
> John
>



-- 
Ahmadou H. DICKO
statistician economist (Ingénieur Statisticien Économiste)
PhD candidate in Climate change economics
Faculty of economics and managment - Cheikh Anta Diop University
West African Science Service Center on Climate Change and Adaptated Land
Use (WASCAL)
Center for Development Research (ZEF) - University of Bonn
email : ahmadou.dicko@ucad.edu.sn
twitter : @dickoah
github : github/dickoa <https://github.com/dickoa>
tel : +221 33 827 55 16
portable: +221 77 123 81 69

[-- Attachment #1.2: Type: text/html, Size: 3267 bytes --]

[-- Attachment #2: rChart.html --]
[-- Type: text/html, Size: 7722 bytes --]

[-- Attachment #3: rChart.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1218 bytes --]

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

[Rick Frankel]

On Thu, Jan 30, 2014 at 12:57:46AM +0000, Ahmadou Dicko wrote:
>    I love slidify too and I think that having similar functionnality in org
>    could be great.
>    I think that you have everything to do that using the html backend, you
>    just need to interface the right Javascript/HTML5 library.
>    In slidify you can use io2012, deck.js, shower and landslide and I know
>    that you can use deck.js through ox-deck and it will not be difficult to
>    create and interface for other library too.
>    For example if you need a nice non Beamer library you can also check
>    ox-reveal which interface reveal.js.

Just to follow-up and expand. It looks like slidy is an interface for
Rstudio to a number of html slide (javascript) libraries, and uses
markdown as it markup language, while providing the ability to execute
R code interspersed with the markup (literate programming/reproducable
results)

Org is it's own markup language and allow interspersing executable
code (and its output) in a literate, reproducable way
(babel). Including, but not limited to, R.

In addion org has export interfaces to multiple output types. For
slideshow there are (at least):

          - ox-s5
          - ox-deck
          - ox-reveal
          - beamer

As well as pdf, html and others.

So it doesn't seem to make sense to use org as a frontend to Rstudio,
but i may be wrong...

rick

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

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Jan 29, 2014 7:46 PM, "Rick Frankel" <rick@rickster.com> wrote:
>
> On Thu, Jan 30, 2014 at 12:57:46AM +0000, Ahmadou Dicko wrote:
> >    I love slidify too and I think that having similar functionnality in
org
> >    could be great.
> >    I think that you have everything to do that using the html backend,
you
> >    just need to interface the right Javascript/HTML5 library.
> >    In slidify you can use io2012, deck.js, shower and landslide and I
know
> >    that you can use deck.js through ox-deck and it will not be
difficult to
> >    create and interface for other library too.
> >    For example if you need a nice non Beamer library you can also check
> >    ox-reveal which interface reveal.js.
>
> Just to follow-up and expand. It looks like slidy is an interface for
> Rstudio to a number of html slide (javascript) libraries, and uses
> markdown as it markup language, while providing the ability to execute
> R code interspersed with the markup (literate programming/reproducable
> results)
>
> Org is it's own markup language and allow interspersing executable
> code (and its output) in a literate, reproducable way
> (babel). Including, but not limited to, R.
>
> In addion org has export interfaces to multiple output types. For
> slideshow there are (at least):
>
>           - ox-s5
>           - ox-deck
>           - ox-reveal
>           - beamer
>
> As well as pdf, html and others.
>
> So it doesn't seem to make sense to use org as a frontend to Rstudio,
> but i may be wrong...
>

Agree on most points, and will be checking out the HTML org options as I
mentioned.

I did want to correct that slidify is not tied to rstudio, even though it
integrates nicely with it. I was playing with it when straight from an R
session within Emacs when I wrote the post.

It also has some nice web publishing features to send the presentation
right to git, dropbox, or rpubs from R, (though I didn't try that outside
of rstudio, so there could be caveats).

John

> rick
>

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]

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

[John Hendy]

An interesting update on this. Aside from some image and code block
stuff, the following works surprisingly well!
- Export Org -> markdown (md)
- Start an R session and `setwd("/path/to/file.md")`
- Run `library(slidify)` and `author("deck")
- Copy the deck/assets folder into the parent directory
- Copy the header code from the resultant deck/index.Rmd file into
exported .md file
- Add three hyphens before each heading (headings are # Slide title)
- Save the file as file.Rmd (vs. file.md)
- From the R session, do `setwd("../")` (running `author("deck")`
changes the working directory to deck/
- Run `slidify("file.Rmd")`

I was coming from Beamer, so all of my generated plots are .pdfs. I
plan to create a new directory and use imagemagic to convert them all
to png or jpg, and then modify my original .org file tailored for
Beamer to use the images vs. pdfs, as well as adding #+attr_html
headings instead of the existent #+attr_latex ones in my current file.

I'll post a test file and the process if anyone is interested in replicating!

It seems that src blocks aren't *always* detected properly in the .md
file, so I need to figure out what's happening there.

I think I should be able to do a pretty easy replace-regexp to replace
[^#] (beginning of line followed by #, indicating a header) with [---
[RET] [RET] #] to automatically populate the slide divisions.

If any rough spots could be identified and tweaked, the current .md
exporter might work brilliantly to create a .Rmd file compatible with
slidify if it's of interest to folks. The boilerplate slidify text at
the beginning is simple enough to populate, and some variables could
set the framework, (io2012, deckjs, etc.), title, author, etc.


Best regards,
John


On Wed, Jan 29, 2014 at 10:26 PM, John Hendy <jw.hendy@gmail.com> wrote:
>
> On Jan 29, 2014 7:46 PM, "Rick Frankel" <rick@rickster.com> wrote:
>>
>> On Thu, Jan 30, 2014 at 12:57:46AM +0000, Ahmadou Dicko wrote:
>> >    I love slidify too and I think that having similar functionnality in
>> > org
>> >    could be great.
>> >    I think that you have everything to do that using the html backend,
>> > you
>> >    just need to interface the right Javascript/HTML5 library.
>> >    In slidify you can use io2012, deck.js, shower and landslide and I
>> > know
>> >    that you can use deck.js through ox-deck and it will not be difficult
>> > to
>> >    create and interface for other library too.
>> >    For example if you need a nice non Beamer library you can also check
>> >    ox-reveal which interface reveal.js.
>>
>> Just to follow-up and expand. It looks like slidy is an interface for
>> Rstudio to a number of html slide (javascript) libraries, and uses
>> markdown as it markup language, while providing the ability to execute
>> R code interspersed with the markup (literate programming/reproducable
>> results)
>>
>> Org is it's own markup language and allow interspersing executable
>> code (and its output) in a literate, reproducable way
>> (babel). Including, but not limited to, R.
>>
>> In addion org has export interfaces to multiple output types. For
>> slideshow there are (at least):
>>
>>           - ox-s5
>>           - ox-deck
>>           - ox-reveal
>>           - beamer
>>
>> As well as pdf, html and others.
>>
>> So it doesn't seem to make sense to use org as a frontend to Rstudio,
>> but i may be wrong...
>>
>
> Agree on most points, and will be checking out the HTML org options as I
> mentioned.
>
> I did want to correct that slidify is not tied to rstudio, even though it
> integrates nicely with it. I was playing with it when straight from an R
> session within Emacs when I wrote the post.
>
> It also has some nice web publishing features to send the presentation right
> to git, dropbox, or rpubs from R, (though I didn't try that outside of
> rstudio, so there could be caveats).
>
> John
>
>> rick
>>

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

[Andreas Leha]

Hi John,

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

> An interesting update on this. Aside from some image and code block
> stuff, the following works surprisingly well!
> - Export Org -> markdown (md)
> - Start an R session and `setwd("/path/to/file.md")`
> - Run `library(slidify)` and `author("deck")
> - Copy the deck/assets folder into the parent directory
> - Copy the header code from the resultant deck/index.Rmd file into
> exported .md file
> - Add three hyphens before each heading (headings are # Slide title)
> - Save the file as file.Rmd (vs. file.md)
> - From the R session, do `setwd("../")` (running `author("deck")`
> changes the working directory to deck/
> - Run `slidify("file.Rmd")`
>
> I was coming from Beamer, so all of my generated plots are .pdfs. I
> plan to create a new directory and use imagemagic to convert them all
> to png or jpg, and then modify my original .org file tailored for
> Beamer to use the images vs. pdfs, as well as adding #+attr_html
> headings instead of the existent #+attr_latex ones in my current file.

Are your pdf plots generated (by R) through babel?  In that case (and
given that you do not rely on absolute positioning) you can make Org /do
the right thing/ for you without the need to call imagemagick manually
in the end.

Making images export correctly across multiple backends is a lot of work
(#+attr_latex and #+attr_html should live happily together), so I'll
stick to a simple example ;-)


--8<---------------cut here---------------start------------->8---
* R plot for multiple backends
You might even consider tikz for the LaTeX route instead of pdf.

#+name: demoplot
#+header: :exports results
#+header: :results graphics
#+header: :file (by-backend (latex "demoplot.pdf") (html "demoplot.svg") (t "demoplot.png"))
#+begin_src R
  ## taken from ?plot
  plot(table(rpois(100, 5)), type = "h", col = "red", lwd = 10,
       main = "rpois(100, lambda = 5)")
#+end_src

#+results: demoplot
[[file:demoplot.png]]
--8<---------------cut here---------------end--------------->8---


This relies on the by-backend macro from Eric Schulte:

--8<---------------cut here---------------start------------->8---
#+begin_src emacs-lisp
  (defmacro by-backend (&rest body)
    `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body))
#+end_src
--8<---------------cut here---------------end--------------->8---




>
> I'll post a test file and the process if anyone is interested in replicating!

Please do so.  I guess that somehow such a process should be
automatable in the end.

[ ... ]

Regards,
Andreas

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

[Charles Berry]

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

> 
> An interesting update on this. Aside from some image and code block
> stuff, the following works surprisingly well!
> - Export Org -> markdown (md)
> - Start an R session and `setwd("/path/to/file.md")`
> - Run `library(slidify)` and `author("deck")
> - Copy the deck/assets folder into the parent directory
> - Copy the header code from the resultant deck/index.Rmd file into
> exported .md file
> - Add three hyphens before each heading (headings are # Slide title)
> - Save the file as file.Rmd (vs. file.md)
> - From the R session, do `setwd("../")` (running `author("deck")`
> changes the working directory to deck/
> - Run `slidify("file.Rmd")`
> 
[much deleted]

John,

You can put the header code into an MD export block (and ignore index.Rmd).
You can add '#+MD: ---' keyword lines to mark new slides.

Then you export to my.Rmd directly (using ravel) and run slidify("my.Rmd").

Graphics 'just work', but you have to mind the spacing to be sure the slides
render nicely.

The file slidify-example.org at

   https://github.com/chasberry/orgmode-accessories/

produces a minimal slidify slideshow with code, computed results, and graphics.

And it has some notes on org --> slidify using the md-knitr backend from 
ox-ravel.

Ideally, a `md-slidify' backend would get written to automagically
produce the yaml header, separate slides based on headline levels, et 
cetera. But that is a low priority right now.


HTH,

Chuck

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

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 3976 bytes --]

On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry <ccberry@ucsd.edu> wrote:
> John Hendy <jw.hendy <at> gmail.com> writes:
>
>>
>> An interesting update on this. Aside from some image and code block
>> stuff, the following works surprisingly well!
>> - Export Org -> markdown (md)
>> - Start an R session and `setwd("/path/to/file.md")`
>> - Run `library(slidify)` and `author("deck")
>> - Copy the deck/assets folder into the parent directory
>> - Copy the header code from the resultant deck/index.Rmd file into
>> exported .md file
>> - Add three hyphens before each heading (headings are # Slide title)
>> - Save the file as file.Rmd (vs. file.md)
>> - From the R session, do `setwd("../")` (running `author("deck")`
>> changes the working directory to deck/
>> - Run `slidify("file.Rmd")`
>>
> [much deleted]
>
> John,
>
> You can put the header code into an MD export block (and ignore index.Rmd).
> You can add '#+MD: ---' keyword lines to mark new slides.
>

Awesome! Hadn't thought of that, and sounds great.

> Then you export to my.Rmd directly (using ravel) and run slidify("my.Rmd").
>
> Graphics 'just work', but you have to mind the spacing to be sure the slides
> render nicely.
>

Hmmm. Could you elaborate on this? I haven't experienced this with R +
ggplot. The presentation I'm working on for tomorrow is on geo-spatial
data with R and I generate a lot of maps. I find that something like
this doesn't produce properly scaled images:

#+header: :file .map.pdf
#+begin_src R :results output graphics :exports results

# install.packages("maps")
library(maps)
world <- map_data("world")

p <- ggplot(world, aes(x = long, y = lat, group = group))
p <- p + geom_polygon(colour = "white")
p

#+end_src

I often get something squarish, which makes the map look really
compressed (see attached). Thus, I seem to need both this (name,
header)

#+name: world-adj
#+header: :file map-adj.pdf :width 9 :height 6
#+begin_src R :results output graphics :exports results

# code from above

#+end_src

and this (right height for latex)

#+begin_center
#+attr_latex: :height 6cm
#+RESULTS: world-map
[[file: world-adj.pdf]]
#+end_center

I guess in this example, the heights are the same, however sometimes
this isn't the case as to use the right height for the slides can goof
with how proportionally big the axis, label, and legend text is and it
requires, in my opinion, waaaay more work to use the theme() arguments
in ggplot2 to tailor them correctly vs. just playing with
:width/:height options and then scaling the final image in the
#+RESULTS section.

I would love to avoid the above if you have more clarification on "just work" :)

> The file slidify-example.org at
>
>    https://github.com/chasberry/orgmode-accessories/
>
> produces a minimal slidify slideshow with code, computed results, and graphics.
>
> And it has some notes on org --> slidify using the md-knitr backend from
> ox-ravel.
>

I'll take a look at this. I wasn't aware of ox-ravel.

> Ideally, a `md-slidify' backend would get written to automagically
> produce the yaml header, separate slides based on headline levels, et
> cetera. But that is a low priority right now.
>

Understood, and inserting the yaml header is not an issue at all. The
#+md: --- code alone removes a good amount of effort.

One other question while we're at it... I noticed that
#+begin/end_center produces this in the output .md file:

<div class="center">
![nil](map.png)
</div>

This doesn't export with slidify. Do I need to define a center <div>
style? I googled around for the proper syntax to center images in
markup and didn't find much other than defining a .css style to go
along with the description. In this case, it seems Org defaults to
[nil] so I'd either replace all of those or .css style all of the
[nil].
- http://stackoverflow.com/questions/255170/markdown-and-image-alignment
(just change the =float : right= argument to centering syntax)


Thanks for the input,
John

>
> HTH,
>
> Chuck
>
>
>
>

[-- Attachment #2: world.pdf --]
[-- Type: application/pdf, Size: 132480 bytes --]

[-- Attachment #3: world-adj.pdf --]
[-- Type: application/pdf, Size: 132478 bytes --]

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

[Charles Berry]

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

> 
> On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry <ccberry <at> ucsd.edu> wrote:
> > John Hendy <jw.hendy <at> gmail.com> writes:
> >
> >>
> >> An interesting update on this. Aside from some image and code block
>
[snip - how John turn org to Rmd to md]


> >
> > John,
> >
> > You can put the header code into an MD export block (and ignore 
> > index.Rmd).
> > You can add '#+MD: ---' keyword lines to mark new slides.
> >
> 
> Awesome! Hadn't thought of that, and sounds great.
> 
> > Then you export to my.Rmd directly (using ravel) and run 
> > slidify("my.Rmd").
> >
> > Graphics 'just work', but you have to mind the spacing to be sure the 
> > slides
> > render nicely.
> >
> 
> Hmmm. Could you elaborate on this? I haven't experienced this with R +
> ggplot. The presentation I'm working on for tomorrow is on geo-spatial
> data with R and I generate a lot of maps. I find that something like
> this doesn't produce properly scaled images:
> 
> #+header: :file .map.pdf
> #+begin_src R :results output graphics :exports results
> 
> # install.packages("maps")
> library(maps)
> world <- map_data("world")
> 
> p <- ggplot(world, aes(x = long, y = lat, group = group))
> p <- p + geom_polygon(colour = "white")
> p
> 
> #+end_src
> 
> I often get something squarish, which makes the map look really
> compressed (see attached). Thus, I seem to need both this (name,
> header)
> 

This is a problem that results from rendering in a square rather than
something proportional to what Mercator used: 202cm x 124cm, I think.

slidify wants to have png files for images, so I think you are stuck
having to set up the size of the device as well as the displayed size
to get nice looking results.

> #+name: world-adj
> #+header: :file map-adj.pdf :width 9 :height 6
> #+begin_src R :results output graphics :exports results
> 
> # code from above
> 
> #+end_src
> 
> and this (right height for latex)
> 
> #+begin_center
> #+attr_latex: :height 6cm
> #+RESULTS: world-map
> [[file: world-adj.pdf]]
> #+end_center
> 
> I guess in this example, the heights are the same, however sometimes
> this isn't the case as to use the right height for the slides can goof
> with how proportionally big the axis, label, and legend text is and it
> requires, in my opinion, waaaay more work to use the theme() arguments
> in ggplot2 to tailor them correctly vs. just playing with
> :width/:height options and then scaling the final image in the
> #+RESULTS section.
> 
> I would love to avoid the above if you have more clarification on "just
work" :)

I wasn't thinking about the case you just demonstrated. I have to use
a line that gives out.width, out.height, fig.width, and fig.height, which
slidify ('knitr' under the hood) uses to render the png and the page as you
did to make something that looks like the Mercator map and still have
the text look OK. See http://yihui.name/knitr/options if the options
listed are not familiar. (knitr chunk options can be put in #+ATTR_RAVEL: 
lines for ravel exports to use them.)


[more deleted]

> 
> One other question while we're at it... I noticed that
> #+begin/end_center produces this in the output .md file:
> 
> <div class="center">
> ![nil](map.png)
> </div>
> 
> This doesn't export with slidify. [snip more details]

Right. IMO, using the knitr tools for dealing with such issues beats
wrestling with the babel and md exporter. i.e. fig.align="center" handles
this. A good part of my motivation for ox-ravel is that I can deal with
fine tuning output from knitr more easily than I can w/ babel exports.


HTH,

Chuck

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

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 3770 bytes --]

On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry <ccberry@ucsd.edu> wrote:
> John Hendy <jw.hendy <at> gmail.com> writes:
>
>>
>> On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry <ccberry <at> ucsd.edu> wrote:
>> > John Hendy <jw.hendy <at> gmail.com> writes:
>> >
>> >>
>> >> An interesting update on this. Aside from some image and code block
>>
> [snip - how John turn org to Rmd to md]
>

[snip]

>> I often get something squarish, which makes the map look really
>> compressed (see attached). Thus, I seem to need both this (name,
>> header)
>>
>
> This is a problem that results from rendering in a square rather than
> something proportional to what Mercator used: 202cm x 124cm, I think.
>
> slidify wants to have png files for images, so I think you are stuck
> having to set up the size of the device as well as the displayed size
> to get nice looking results.

Indeed. I've had to deal with that when exporting to html. Was just
curious if there was a more elegant way, and it seems there's not, but
I suppose it's just adjusting syntax from #+attr_latex stuff to the
knitr equivalents, which isn't bad to know anyway since I've been
working more with RStudio.

[snip]

>> I would love to avoid the above if you have more clarification on "just
> work" :)
>
> I wasn't thinking about the case you just demonstrated. I have to use
> a line that gives out.width, out.height, fig.width, and fig.height, which
> slidify ('knitr' under the hood) uses to render the png and the page as you
> did to make something that looks like the Mercator map and still have
> the text look OK. See http://yihui.name/knitr/options if the options
> listed are not familiar. (knitr chunk options can be put in #+ATTR_RAVEL:
> lines for ravel exports to use them.)

Thanks for the reference.

>
> [more deleted]
>
>>
>> One other question while we're at it... I noticed that
>> #+begin/end_center produces this in the output .md file:
>>
>> <div class="center">
>> ![nil](map.png)
>> </div>
>>
>> This doesn't export with slidify. [snip more details]
>
> Right. IMO, using the knitr tools for dealing with such issues beats
> wrestling with the babel and md exporter. i.e. fig.align="center" handles
> this. A good part of my motivation for ox-ravel is that I can deal with
> fine tuning output from knitr more easily than I can w/ babel exports.
>

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?

I'm also getting some odd code highlighting (see attached). Every once
in a while, it's like it can't differentiate non strings (black) from
strings (red)? Any idea why that might be? I still have some
attr_latex stuff to prune out, so perhaps that's gunking up proper
code recognition... then again, any of my latex options shouldn't be
touching the contents of ```{r} chunks, so I'm perplexed.

Other than that and figuring out my plot/image strategy, I think this
will work wonderfully! I won't be able to transition my slides to
Slidify by tomorrow, but am quite hopeful for transitioning in the
future! Love the idea of embedding shiny apps or d3 right in a
presentation vs. having to open a browser :) Also makes it so much
easier to share presentations, embed them in a web page, or whatnot.
No more things like relying on box/dropbox/google drive to have
in-browser PDF displays!


Thanks so much for chiming in -- I'd not seen ox-ravel before and am
really glad to have discovered it!
John

>
> HTH,
>
> Chuck
>
>
>
>

[-- Attachment #2: 2014-02-07_233046.png --]
[-- Type: image/png, Size: 36771 bytes --]

[-- Attachment #3: 2014-02-07_233122.png --]
[-- Type: image/png, Size: 80355 bytes --]

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

[John Hendy]

On Fri, Feb 7, 2014 at 11:38 PM, John Hendy <jw.hendy@gmail.com> wrote:
> On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry <ccberry@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. 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?

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.


Thanks again,
John

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

[Charles Berry]

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.

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

[John Hendy]

On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry <ccberry@ucsd.edu> 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=<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.

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.

>
>

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

[Charles Berry]

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

> 
> On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry <ccberry <at> ucsd.edu> wrote:
> 
[snip]

> > 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?
> 

'References' refers to noweb references. See

   http://orgmode.org/org.html#noweb 


> > 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.
> 
> 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? 

Almost. ox-ravel does not call knitr. The ravel backends advice 
`org-babel-exp-do-export' when a ravel backend runs so R code src blocks 
are not run, but are turned into chunks (for knitr, Sweave, or ...) and 
exported as such. 

When you want to actually process the resulting document, you have to call 
on knitr or some other R report generator to do the work.

> 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)?

Correct for R src blocks. But emacs-lisp and other languages are treated as 
under the parent backends.

> 
> 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.
> 

In R scr blocks, :eval is ignored by ravel and so need not change when 
ravel is run.

[snip]

> 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.
> 

It's not related to ox-ravel, which uses the same transcoders as the parent 
backends for everything except inline src and src blocks.

I'm not sure how to get what you seem to want.

Maybe use a custom link 

  http://orgmode.org/org.html#Adding-hyperlink-types

or ask about html/md links in a fresh thread?

HTH,

Chuck

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

[John Hendy]

On Sun, Feb 9, 2014 at 10:16 PM, Charles Berry <ccberry@ucsd.edu> wrote:
> John Hendy <jw.hendy <at> gmail.com> writes:
>
>>
>> On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry <ccberry <at> ucsd.edu> wrote:
>>
> [snip]
>
>>
>> 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?
>
> Almost. ox-ravel does not call knitr. The ravel backends advice
> `org-babel-exp-do-export' when a ravel backend runs so R code src blocks
> are not run, but are turned into chunks (for knitr, Sweave, or ...) and
> exported as such.
>
> When you want to actually process the resulting document, you have to call
> on knitr or some other R report generator to do the work.
>

I think I stated it ambiguously before. I think we're on the same
page. Org -> Rmd. Then process Rmd in an Emacs R session. If you
re-export from Org -> Rmd, only new code block changes are re-run,
correct?

>> 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)?
>
> Correct for R src blocks. But emacs-lisp and other languages are treated as
> under the parent backends.
>
>>
>> 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.
>>
>
> In R scr blocks, :eval is ignored by ravel and so need not change when
> ravel is run.

Ah, that makes more sense. I guess I had all mine set to :eval no and
never experienced that ox-ravel doesn't actually run them. Thanks for
that.

>
> [snip]
>
>> 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.
>>
>
> It's not related to ox-ravel, which uses the same transcoders as the parent
> backends for everything except inline src and src blocks.
>
> I'm not sure how to get what you seem to want.
>

What I mean is how do I just add an image via existing Org syntax and
get it sized correctly in the Org -> Rmd -> html process? None of the
attributes seem to be carried through to markdown with ox-md or
ox-ravel. So my question might be more clear if I said, "Say you have
an image that's 1600x900px and you want it in your slidify deck at
400px tall. How would you do that?"

ox-ravel works fine by just specifying knitr fig.height/width if
you're going to generate your plots during the process of knitting.
You create the plot at exactly the size you want. But how might you
resize an existing plot depending on the format? If you want an html
equivalent to the latex article class, you might want a different plot
size than if you want to export to slidify. Would one have to go
through and replace all the fig.height/width arguments and re-run all
the plot code just to get proper image sizing? Once there are
perfectly good images laying around... it doesn't seem like one should
have to re-generate them just because a different size is desired.

> Maybe use a custom link
>
>   http://orgmode.org/org.html#Adding-hyperlink-types
>
> or ask about html/md links in a fresh thread?

I posted another ML post along these lines earlier today. Since
markdown is just a middle destination onto html, I'm interested in
getting Org's built-in image attributes passed along for the whole
trip. I don't see a way to even center an image at present. The direct
<img > tag could be put in Org... but that breaks the spirit of
keeping Org's syntax flexible enough to let me export to another
backend if I want. Thus, the ideal goal would be something like:

#+begin_center
#+attr_latex: :height 6cm
#+attr_html: :height 400px
#+attr_ravel: :height 400px
[[./img.png]]
#+end_center

Thus I get a centered image at some appropriate size for each backend.
Otherwise I'll be having to do #+begin/end_latex and #+begin/end_html
for every image in my document.

Does that make more sense?


John

>
> HTH,
>
> Chuck
>
>

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

[Nicolas Goaziou]

Hello,

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

> One other question while we're at it... I noticed that
> #+begin/end_center produces this in the output .md file:
>
> <div class="center">
> ![nil](map.png)
> </div>

This "nil" looks like a bug. What should be expected instead?


Regards,

-- 
Nicolas Goaziou

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

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Feb 8, 2014 3:32 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
>
> Hello,
>
> John Hendy <jw.hendy@gmail.com> writes:
>
> > One other question while we're at it... I noticed that
> > #+begin/end_center produces this in the output .md file:
> >
> > <div class="center">
> > ![nil](map.png)
> > </div>
>
> This "nil" looks like a bug. What should be expected instead?
>

Typical markup would be a description string on some sort. Maybe just 'img'
for general images and the content of #+name for Babel results?

John

>
> Regards,
>
> --
> Nicolas Goaziou

[-- Attachment #2: Type: text/html, Size: 935 bytes --]

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

[Nicolas Goaziou]

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

> Typical markup would be a description string on some sort. Maybe just 'img'
> for general images and the content of #+name for Babel results?

OK. I fixed it in maint. "img" will be always used as alt text. I also
fixed caption location.

Thank you.


Regards,

-- 
Nicolas Goaziou