Custom writers: inspecting custom extensions early

[bpj]

In my custom Pod writer I have some custom extensions which control how elements which have no counterpart in Pod, like SmallCaps, Strikeout, Underline, Subscript, Superscript and mark (which is a class on a Span) are rendered, basically four alternatives:

0. Textual: [strikeout: CONTENT].
1. Pandoc-like punctuation character delimiters.
2. "Fancy" Unicode brackets as delimiters: ⸠STRIKEOUT⸡, ⸢SUPERSCRIPT⸣, ⸤SUBSCRIPT⸥.
3. Faking with Unicode combining marks like LONG STROKE OVERLAY for strikeout.

Naturally the custom extensions for selecting these alternatives are mutually exclusive and I want to check if they are set and that they are not contradicting each other rather early and only once because checking every time each of the functions for each of the element types is called is time and resource consuming and makes the source code cluttered.

Would the Pandoc function be a good place to check? I'm thinking that if the traversal is bottom-up it might not be, because if things are bad it is better to error out early. The best alternative is probably to have a sentinel variable and then in each element type handler check the sentinel variable and if it is still false call a helper function which does the extension sanity check and sets the sentinel variable to true unless it errors out.

Or is there a better way?

[tarleb]

There's a similar issue in pandoc, where we have the extensions wikilinks_title_before_pipe and wikilinks_title_after_pipe. We take the easy way out, the commit which introduced the extensions says:

Pandoc will use wikilinks_title_after_pipe if both extensions are enabled.

The Pandoc function is a good place to check for such conflicts. Custom writers start at the root, as that gives maximum control over the rendering process.

[bpj]

Thanks @tarleb! At first I thought to just document a precedence order, but I found that the best order to check for the extensions in the handlers was not the order of precedence which would make most sense for a human, so I want to decouple the two, and then making some of the extensions mutually exclusive makes the most sense. Being able to check for it efficiently in the Pandoc handler is a great relief!

[tarleb]

Adding some inconsequential technical details: the entrypoint, i.e., the first function to be called, is getmetatable(Writer).__call. But that function exists only for convenience, it just calls Writer.Pandoc. So technically Writer.Pandoc isn't the entrypoint, but it makes sense to treat it as such.