How would preprocessors be treated in commonmark?

1

I’ve been looking over my resume the source is done in markdown but rendered by pandoc (very convenient indeed).

However I’m finding myself maintaining multiple versions of resumes to fit different industries manually. Keeping them all in sync is proving to be difficult.

Ideally what I would have is something like how the “C preprocessor” functions, where I can includes/exclude pieces of code based on simple logic.

However C preprocessor might look a bit ugly if used with markdown…

#IF PROGRAMMING_JOBS || LUA_JOBS

# Adrix Consulting (2013 - 2043)
- Was good at drawing pictures
- Was good at programming in lua for cats

#ENDIF

While this probbly should not be part of the primary commonmark standard. Is there a community recommendation section to point out the best practices for preprocessing common-mark documents? Do we have a community wiki for “community recommended approach”?

As for possible approach for resume section handling specifically. Perhaps we can include/exclude based on css tags.

# Adrix Consulting (2013 - 2043) { .lua .cats }
- Was good at drawing pictures
- Was good at programming in lua for cats
2

HTML is valid Markdown, so you can take advantage of this rather than coming up with a custom syntax.

You could use HTML comments; the whole document would be rendered except for comments normally. A preprocessor that uses your own format could then skip or include particular blocks based on the content of the comments.

Another approach would be to wrap each section in HTML section tags and use data attributes, e.g. <section data-language="lua">.

3

oh can that be already done via pandoc to pdf? or will that only be for pandoc html output? also how would i specify what to render in pandoc command parameter?

Or does such capability not exist yet in pandoc?

Oh and btw, I prefer the section html tag over the “comment out”, since I by default want to render everything if preprocessor is deactivated. Commenting things out would be a bad idea in that case.

4

I haven’t looked at it. This is just a general strategy that would allow you to keep using Markdown for the resume document; you’d probably need to write the preprocessor yourself. There are many libraries which can parse HTML documents already, so if you went with the section tag approach you would convert the document in this order: Markdown → HTML → HTML Post-processor (to strip out HTML based on data attributes) → PDF.

5

Did a bit of research of various template languages. Here is some interesting ones I can find (Or think of):

This hopefully would be a good selection for people trying to find the right preprocessor for whatever it is they are trying to do. I personally am attracted to Gpp, since it looks pretty low fat and there is already a pandoc and gpp wrapper for it in pandoc-gpp

Gpp

<#ifdef HTML>
# Adrix Consulting (2013 - 2043)
- Was good at drawing pictures
- Was good at programming in lua for cats
<#endif>

Server Side Include

<!--#if expr="${lua}" -->
# Adrix Consulting (2013 - 2043)
- Was good at drawing pictures
- Was good at programming in lua for cats
<!--#endif -->

Liquid Template

{% if lua %}
# Adrix Consulting (2013 - 2043)
- Was good at drawing pictures
- Was good at programming in lua for cats
{% endif %}

Box Style Preprocessor (doesn’t exist yet)

!IF lua
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Adrix Consulting (2013 - 2043)
- Was good at drawing pictures
- Was good at programming in Lua for cats
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7

With pandoc’s Markdown (but not CommonMark), another option is to put the sections in specially marked divs (which pandoc will parse as native Div elements in the AST), then use a pandoc “filter” to remove them.

For filters with CommonMark, see lcmark. One could write an lcmark filter that omitted sections bracketed by (e.g.) specially marked HTML comments.

1 Like