Home → Suggestions →

Pre- and Post- Processors

• Edit

AJ

04 Jul, 2012 03:13 AM

I've got a few ideas for custom markdown processors to deal with my HTML5 and PDF generation workflows, but I don't necessarily want to NOT call the built in mmd processor in Marked.

One idea - that shouldn't be hard to implement - would be to add preferences to Marked for running a pre- mmd and post mmd- processor. These would work exactly as the current custom processor, they just get optionally called before the main mmd processing run, and then after.

I could then build some of my ideas into much simpler custom processors (e.g. simple token replacement like %date to today's date kind of thing) and leave the heavy md lifting to Marked / mmd.

Any thoughts?

Cheers,

• AJ

ps : Marked rules!

1. Support Staff 1 Posted by Brett on 04 Jul, 2012 03:38 AM

   

   Yep, I'm almost finished with the preprocessor setup for 1.5. You'll be able to assign any script to run between the initial processing (when it handles code blocks and file includes) and the actual rendering (internal or custom processor), so replacing tokens and other regex work will be easy. I also have a syntax you can use to define a preprocessor script within the metadata of a file and override the default settings, allowing you to have different processors for different files, even of the same type. I haven't started a post-processor yet, and might wait on that one. What would you do with it if you had it? Most of the things people have suggested are better solved by external scripting and don't need to fire every time Marked updates a preview. Curious what your use case would be for that.

   -Brett

   • Edit

2. 2 Posted by AJ on 04 Jul, 2012 04:27 AM

   

   Thanks for the response Brett.

   My current thoughts for a PRE-processor are based on implementing some very simple extensions to mmd, that don't invent a new syntax that's more complicated than either md or html (as other extensions seem to be). On my list now are:

   wrap & in .amp class
   See http://css-tricks.com/snippets/css/fancy-ampersand/

   Some *very* simple general syntax to attach specific classes to elements. Have to think on this.

   Very simply token replacement, using "(token)", e.g. "Document printed on (date)".
   Tokens would be (date), (time), (title), (author), (anything from the meta header), (#results from shell cmd)...
   This seems like a good simple extension to md, though others may disagree!

   Use "--> my text" to create <aside>my text</aside>

   Maybe something to deal with HTML5 <header> <footer> <section> and <article> tags somehow.
   Need to think this through.

   wrap // and /* */ blocks in <div class="comment"></div>
   why? To allow comments in body of doc as guides to authors, that can either be hidden via css or output as needed.
   
   The POST-processor idea is based more on intuition than anything at present, and I suspect it could be a way to deal with PDF page numbering in some way. One of my goals is to produce well formatted PDFs with cover pages, TOCs with page numbers, and headers / footers on each page, showing page numbers as well. Nothing to hard then!

   Perhaps some form of post-processor could work out where page breaks are, count the pages, go back and put in page numbers??? Haven't got my head around this as yet. Damn you Webkit printing engine!

   Cheers,

   - AJ

   ps : Happy to be a beta tester if you want. I'm an iOS app developer / consultant, originally from a Windows and .NET background, but an xcoder for a couple of years now. I'm completing an app for a client at present, and using Marked heavily to produce in-app content and documentation.

   • Edit

3. Support Staff 3 Posted by Brett on 04 Jul, 2012 05:10 AM

   

   The preprocessor makes sense, that's why I added it. I had a lot of erb templates containing Markdown and just needed to process the <%= %> tags before it ran, but I can think of a dozen other uses for it off the top of my head, including some you mentioned. Post-processing I'm still unsure about adding. The use case you suggest would be something that would run after HTML otuput, and at that point you could just save your file and run the script yourself. It's not something you'd want running *every time you save*. I'll contact you directly about the beta.

   • Edit

4. 4 Posted by AJ on 04 Jul, 2012 05:21 AM

   

   All sounds good.

   I think there's plenty of people (like me) who **do** want some things to happen *everytime you save*, though I understand your need to keep Marked free of bloat.

   Of course, if there's now a pre- and a main processor I could actually fudge these into being main (i.e. mmd) and post- (roll my own), just by tweaking the settings :)

   • Edit

5. Brett closed this discussion on 26 Aug, 2012 08:27 PM.