This project is read-only.

Compatibility with Rmarkdown (Pandoc) and Slidify-Rmarkdown

Dec 18, 2014 at 6:33 PM
Hi, @Daan

Would you be interested in making the syntax of Madoko more compatible with the Rmarkdown (based on Pandoc), or even the Slidify-Rmarkdown format?

Alternatively, it would be nice if the .md or .Rmd files previously prepared for Rmarkdown or Slidify-Rmarkdown could be imported into Madoko effortlessly, with all the equivalent syntax across the several platforms retained in the new .mdk files.

Pandoc markdown
http://rmarkdown.rstudio.com/authoring_pandoc_markdown.html

Rmarkdown:
http://rmarkdown.rstudio.com/
slides - https://rpubs.com/trestletech/usermd

Slidify:
http://slidify.org/
slides - http://slidify.org/samples/intro/

Thanks.
Andrew
Dec 18, 2014 at 7:36 PM
Hi Andrew,

I am very interested to make Madoko as compatible as possible with other systems. In fact, it should be very compatible with Pandoc since I like that system a lot (being a Haskell guy).

However, I am hesitant to make Madoko compatible with non-generic extensions that are particular to just one implementation. For example, in Slidify the 'three-dash slide separator' is of that kind (and unnecessary). Moreover, three dashes are also used for horizontal lines in markdown so I would not be keen on adding support for that.

In Madoko, I tried to be compatible as far as possible with all major implementations, and then I added very generic features that can be used to have users add their own custom rendering through custom blocks and CSS styling.
These generic mechanisms allow for example really high quality PDF output where one can write full academic articles fully in Madoko.

Anyway, one future direction is to allow generic plugins that process parts of the document: already this happens for LaTeX math where Madoko uses LaTeX to render the formulas in the document. But in general, we would like to run say, "R" on parts of code and render nice graphs from that (as in Rmarkdown). I am actively thinking about this and perhaps R is a great place to start since the KnitR package is already doing most of the work :-)

Btw. if you have specific syntax that doesn't work in Madoko let me know -- it may be by design but I am certainly willing to extend Madoko syntax to accommodate common idioms.
Dec 18, 2014 at 9:28 PM
Thanks for the reply, Daan. I very much look forward to Madoko's capability of rendering R results.
Dec 21, 2014 at 4:43 AM
Would it be possible for Madoko to support the following to increase the compatibility with Rmarkdown (Pandoc)?

a. speaker notes require <div class="notes">, based on pandoc
<div class="notes">
Ans: 12345
</div>
b. Can build up items in slides using {. build} slide attribute
## second slide { .build }

c. Incrementally revealed list (assuming -i option not used in pandoc, i.e. incremental: true not used in Rmd)
> - Test 1
> - Test 2
> - Test 3

daan wrote:
Hi Andrew,
...
Btw. if you have specific syntax that doesn't work in Madoko let me know -- it may be by design but I am certainly willing to extend Madoko syntax to accommodate common idioms.
Dec 21, 2014 at 5:50 PM
THanks for the suggestions - I'll add some rules to make it more compatible.
  • (a) you can already do this in Madoko and it is compatible. Note that for revealjs speaker notes you need to use an
    <aside> block instead:
    <aside class="notes">
     Ans: 12345
    </aside>
  • (b) Thinking about adding support; what does it exactly mean? That all lists in that slide are incrementally revealed? Or everything under it, include paragraphs or images?
  • (c) Hmm, not sure about this one. It is easy to do though -- just add some javascript that adds the .fragment class to li list items directly under a quote>ul.
  • About the "-i" or "incremental:true" option, you can make all lists incremental by adding a metadata rule, for example:
    ~ul,~ol : .fragmented
    This will add the .fragmented class to each list and thus all lists in your presentation will be incrementally revealed.
Dec 22, 2014 at 8:02 PM
Hi, I added support for ".build" where all immediate children are incrementally revealed. (.build is an alias for .fragmented).
Also added the funny 'lists within quotes' -- only works for HTML though -- not beamer output (where it is just a list inside a blockquote)
Dec 24, 2014 at 12:12 AM
Thanks and much appreciated.

Just want to make a remark here regarding "the funny 'lists within quotes' " when used together with {.build} or the underlying {.fragmented}. When they are used together, the effect is almost like what's expected and intended. The (inessential) unexpected part is the extra click required before the first list item to appear, which I feel perfectly fine.

However, despite the presumed equivalence between "the funny 'lists within quotes' " and the {.fragmented} applied to a list, when {.fragmented} is used on a slide containing a list with {.fragmented} applied to it as well, the ultimate effect is very far from expected and intended. If you feel worthy, perhaps a warning can be added to the relevant part of the reference manual. Thanks.
Dec 24, 2014 at 12:25 AM
Just a clarification. Pandoc uses the <div class="notes"> block to convert speaker notes, and this works for both reveal.js and beamer. This is why it does not use <aside class="notes">, which is specific to reveal.js. In other words, if the goal is to be compatible with Pandoc, a <div> block should be supported. .md files with speaker notes previously prepared for conversion into reveal.js slides using Pandoc must be pre-processed before they can be correctly processed by Madoko.

daan wrote:
  • (a) you can already do this in Madoko and it is compatible. Note that for revealjs speaker notes you need to use an
    <aside> block instead:
    ``` <aside class="notes">
    Ans: 12345
    </aside>
Dec 24, 2014 at 6:34 PM
I see. In Madoko you should use the ~ Notes custom block as that is properly translated to both the HTML and LaTeX backend (using simple metadata rule). A <div> (or <aside>) block is always treated as inline HTML and just output to the HTML backend -- just as ~ TexRaw just goes to the LaTeX backend. That Pandoc takes a special action for a div block seems quite odd :-(

So, for compatability I will add some Javascript to make sure <div class="notes"> blocks are translated to an <aside> for Revealjs output. However, such blocks will not show up in the beamer output since those are really just inline HTML blocks.
Dec 24, 2014 at 11:04 PM
Sorry for my ignorance about this but wouldn't it be nice if <div class="notes"> blocks could be interpreted (translated by Madoko?) as though they are the native ~ Notes blocks and then handle the blocks as usual?

I just hope that users of the Rmarkdown platform can with little changes (perhaps just the metadata) reuse their files in Madoko if they see an incremental value in trying it. And if they end up wanting to move back, they can do so with again just a change in the metadata. And until Madoko can render R results, R users can't give up Rmarkdown.
Dec 25, 2014 at 3:12 AM
Yeah, I see what you mean. I just pushed the latest update where at least <div class="notes"> are working (just like <aside class="notes">) for added compatibility.

Should be good enough for now :-) Btw. also in this update are visible speaker notes in the preview.
Jan 4, 2015 at 9:52 PM
Please see if Madoko can also have instant previewing of the results of R codes like the following implementation. Thanks for your consideration.

https://github.com/swarm-lab/editR

editR

editR is a basic Rmarkdown editor with instant previewing of your document. It allows you to create and edit Rmarkdown documents while instantly previewing the result of your writing and coding. It also allows you to render your Rmarkdown file in any format permitted by the rmarkdown R package.

daan wrote:
Hi Andrew,

...
Anyway, one future direction is to allow generic plugins that process parts of the document: already this happens for LaTeX math where Madoko uses LaTeX to render the formulas in the document. But in general, we would like to run say, "R" on parts of code and render nice graphs from that (as in Rmarkdown). I am actively thinking about this and perhaps R is a great place to start since the KnitR package is already doing most of the work :-)