Ah, very good! A lot to be aware of here, glad we've got it sorted out.

On Friday, April 25, 2014, Jonathan <notifications@github.com> wrote:

> In R/output_format.R:
>
> > +}
> > +
> > +# merges two output formats
> > +merge_output_formats <- function (base, overlay)  {
> > +  structure(list(
> > +    knitr = merge_lists(base$knitr, overlay$knitr),
> > +    pandoc = pandoc_options(
> > +      to = merge_scalar(base$pandoc$to, overlay$pandoc$to),
> > +      from = merge_scalar(base$pandoc$from, overlay$pandoc$from),
> > +      args = c(base$pandoc$args, overlay$pandoc$args)),
> > +    clean_supporting =
> > +      merge_scalar(base$clean_supporting, overlay$clean_supporting),
> > +    pre_processor =
> > +      merge_function_outputs(base$pre_processor, overlay$pre_processor, c),
> > +    post_processor =
> > +      merge_function_outputs(base$post_processor, overlay$post_processor, c)
>
> Thanks, this is clear now. merge_scalar won't quite do everything we need
> here, though, since (a) it appears it's possible for the post-processor to
> produce a new output file, which needs to be chained into the next
> post-processor, and (b) the ordering is sensitive: in the
> ioslides/html_document case, it's necessary to invoke the html_document
> post-processor *last*, since the HTML-preserved chunks are not visible
> until ioslides is done with its own post-processing step. I have this fixed
> here: cb2537a<https://github.com/rstudio/rmarkdown/commit/cb2537ae286cb9128f1a931183bd60cce5099867>
>
> It feels a little backwards to run the most specific post-processor first,
> but you could also think of this as the overlay post-processors producing a
> common format understandable to the base post-processor (like a derived
> class doing work and then invoking a method on the base class with
> partially digested data).
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/rstudio/rmarkdown/pull/74/files#r12008130>
> .
>