Documentation

This is similar to Block. Having our own datatype has some advantages:

• We can extend it with slide-specific data (eval, reveals)
• We can remove stuff we don't care about
• We can parse attributes and move them to haskell datatypes
• This conversion can happen in a single parsing phase
• We can catch backwards-incompatible pandoc changes in this module

We try to follow the naming conventions from Pandoc as much as possible.

See comment on Block.

Depth-First Traversal of blocks (and inlines).

Depth-First Traversal of inlines (and blocks).

A variable is like a placeholder in the instructions, something we don't know yet, dynamic content. Currently this is only used for code evaluation.

Finds all variables that appear in some content.

A counter is used to change state in a slide. As counters increment, content may deterministically show or hide.

Number of reveal steps in some blocks.

Construct the reveal state for a specific step.

Construct the final reveal state.

This does a deep traversal of some blocks, and returns all reveals that should be advanced in-order.

Apply revealToBlocks recursively at each position, removing reveals in favor of their currently visible content.

Stores the state of several counters.

Render a reveal by applying its constructor to what is visible.

This determines how we construct content based on the visible items. This could also be represented as `[[Block]] -> [Block]` but then we lose the convenient Eq and Show instances.

A reveal sequence stores content which can be hidden or shown depending on a counter state.

The easiest example to think about is a bullet list which appears incrmentally on a slide. Initially, the counter state is 0. As it is incremented (the user goes to the next fragment in the slide), more list items become visible.