Tricks for working with custom processors

There are myriad options for making custom processors smarter.

First, when you enable a processor or preprocessor, you'll see small indicators in the bottom menu bar:

If you do not check "automatically enable for new windows," the indicators will show up as empty outlines. Clicking them will turn the processor (green) or preprocessor (yellow) on or off for the current window only, so you can use it only when needed. Once clicked, the processor will stay on for as long as the window is open (or until you turn it off).

You can also turn a processor or preprocessor on for specific documents automatically using metadata. If you put the following anywhere in your document (it can go inside of HTML comment tags, too) it will set the default for that document:

Custom Processor: true

This works for "custom preprocessor" as well. See Per-document settings in the documentation for more info.

Advanced tricks

You can also, with a little scripting, have your processor auto-detect whether or not it should run. For example, I have a custom processor that checks to see if the document contains YAML headers and certain keys, and if it does it processes it with Kramdown and custom handlers for my own blog. If not, it returns "NOCUSTOM" and processing proceeds as usual without the custom processor. NOCUSTOM returned on STDOUT will cancel the custom processor.

You can use Marked's available environment variables as variables to determine which of multiple processors to run. For example, checking $MARKED_EXT will return the extension of the document being processed, so you can fork a script to run different processors based on the extension of the file. You can also check the $MARKED_PATH to get the full POSIX path of the current file so you can base logic off of the title or containing folder.