Enclose sections

[flupe]

I really would like an option similar to pandoc's --section-divs option, so that document sections are properly enclosed, and current selected sections could be properly highlighted.

For example,

# Document

A paragraph

## A subsection

With some text

## Another subsection

### With a child

would result in the following HTML:

<section id="document">
  <h1>Document</h1>
  <p>A paragraph</p>
  <section id="a-subsection">
    <h2>A subsection</h2>
    <p>With some text</p>
  </section>
  <section id="another-subsection">
    <h2>Another subsection</h2>
    <section id="with-a-child">
      <h3>With a child</h3>
    </section>
  </section>
</section>

The current extension system doesn't seem to allow this kind of transformations --- or at the very least I wasn't able to figure out how --- and because internals of the library are hidden, I cannot implement this outside of the library by hacking my own rendering function.

Would love some discussion about whether this would be worth adding to the library, and how.
I would perfectly understand if it's outside the scope of MMark.

[flupe]

I have implemented the behaviour described above on my fork. It's not particularly pretty but does the job.
Essentially, we fold over top-level blocks to find the document structure:

• If it's a heading, we check if it closes or opens new sections and render it manually¹.
• If it's something else, we render it using the already existing rendering functions, thus accounting for extensions.

This makes the assumption that document headings only appear at the uppermost level (in mmarkBlocks), which they should anyway.

Let me know if there's any interest in this thing.

Footnotes

1. We could also render headings with the existing rendering function, but currently this function automatically adds an id to every heading, which we obviously want to avoid. We could turn auto-ids into an extension, too. ↩

[mrkkrp]

I think the best thing we can do here is to expose more internals of MMark, e.g. in Text.MMark.Internal to facilitate custom logic like this. I'm open to a PR that does that.

[mrkkrp]

I have just merged #116 that exposes enough internals to make it possible to write custom renders.