Currently playing whack a mole with parsec combinators. Fix one parser bug, re-break another!

I’d kinda like to separate out the parsec bits from the pandoc bits so I can ignore the latter whilst I iterate on the former. But it’s not entirely possible because the parser needs to emit parsec types. I might be able to avoid the pandoc monad wrapper at least. Maybe more

It’s also strange to me that the pandoc testing strategy is entirely around the top-level function you export from a reader. No unit tests of any utility functions, which is an approach I prefer. I also prefer in-module tests (so you can test stuff you don’t export). My tastes may not align with the zeitgeist.

I really like HTF which uses a pre-processor to discover your test functions (you must name them e.g. `test_foo`) but it is an approach with serious limitations. Tasty (the framework Pandoc uses) has a companion library `tasty-th` (or similar) which does discovery using template Haskell, which seems like a good approach. I might try it during dev; I’m not sure pandoc would accept another dependency for a new reader.

My primary reason for working on a moinmoin reader for pandoc has gone away (change of strategy for migrating Debian’s wiki) but I’ve kept working on it anyway.