Pluggable Markdown extension support?

[tedmyoung]

Now that two extensions to the "standard" Markdown are supported, it'd be great if there was some pluggable way to support more variants. For example, I'm an author using LeanPub (http://leanpub.com), which uses Markdown as the input for generating ebooks. The variant they use is based on Kramdown, with extensions for sidebar/text blocks (asides, warnings, etc.). It'd be great to have that supported in MarkdownPad without requiring you to keep it up-to-date. I'm sure there are others who use other variants (e.g., MultiMarkdown) who would also appreciate this.

[Mightymuke]

Would there any value in also extending this to support other types of wiki syntax (confluence, trac, etc)?

[evanw]

I'm definitely interested in adding support for additional Markdown processors, and I plan to make more available whenever possible.

Specifically regarding Leanpub, I contacted the founders a few months ago to talk about their proprietary implementation of Markdown, and to identify how I could add support for it in MarkdownPad.

Unfortunately, the Leanpub team is just starting the work to formally define their spec, meaning that a real-world implementation of a processing library is still a ways out. Once they formally define their Markdown spec, work could begin to build a processing API (either local or web-based) to perform the conversion.

I can't say for sure whether Leanpub themselves will eventually create a public API for their Markdown implementation; due to their limited resources, it may come down to some enthusiastic community members building some type of open-source implementation based on their spec. Regardless of what happens, I'll keep my ear to the ground on the issue and do whatever I can to help add Leanpub support to MarkdownPad.

Regarding other Markdown implementations like MultiMarkdown: Same story - the only real limiting factor right now is lack of access to an API. It would technically be possible to shell out to MultiMarkdown, wait for its response, then post-process the converted data, but this would all be done outside the context of MarkdownPad. An ideal solution would be if a .NET API was made available for MultiMarkdown. I'll continue working on the possibility of adding MMD support through other avenues in the meantime.

Thanks for the feedback!

[tedmyoung]

Thanks for the detailed reply, Evan.

I'd love to help create at least an 80% solution for the LeanPub Markdown variant, but I'm not at all able to create a .NET API. I can create a Java API, or a micro-server REST-based API, if that helps.

I'm assuming an API that would be useful for MarkdownPad would be something more granular than the entire file? If so, that'd be useful, because then in my 80% solution, for each segment of text, I could say "use the default processing for this segment" or "here's my processed output for this segment", saving me from having to re-invent what's already supported (headings, text styles, etc.) and focusing on LeanPub-specific things (sidebars, etc.). Though admittedly that might not help too much -- this is just an off-the-cuff reply.

Regardless, it'd be nice if there was a way for the API to say "this is the same as Markdown" and "this is different/additional, so I'll handle it".

[Jean]

Just wondering if there has been any progress on adding Leanpub support? Or if there is any way I can manually add the text block icons (warnings, tips etc.) with CSS?

[tedmyoung]

Since a recent comment put this back on my mind, I'm wondering what the possibilities are here. What would MarkdownPad need from a library, i.e., if you hand it some markdown text, what are you expecting in response? HTML? LaTeX? Something else?

[evanw]

@tedmyoung Thanks for the follow up, I'm glad to see there's still interest in this functionality.

I just wanted to let you know that I'm starting work on a project to add public extensibility to MarkdownPad's Markdown processing system. This would allow custom Markdown processors to be created by the community.

It'll be simple at first, but I'll try to keep you updated on my progress to let you know when I have an idea of the programming interface required to interact with this system. And if you don't hear from me in a suspicious amount of time, just ping me to make sure I didn't forget to update this thread

[simoncropp]

+1

I think for my purposes i would need the ability to have a custom IMarkdownProcessor but would also need to know the path to the md file being processed

[evanw]

@simoncropp What are your thoughts on unsaved documents? (no path on disk yet)

[simoncropp]

@evanw would be happy with getting a null for the path. then perhaps call a method when it is saved?

[evanw]

@simoncropp You mean the external library would call a method?

[simoncropp]

@evanw when mdPad saves it would somehow notify the render extension. perhaps ConvertMarkdownToHTML could take a context parameter. this context object could be a bucket for things like the current file path

[evanw]

@simoncropp Currently, rendering is initiated primarily based on keypress (so an external library would be called quite often). For your use case, are you seeking something that only gets called occasionally, like at file save?

[simoncropp]

@evanw nope. i want to take over the current rendering. so on keypress is fine. but to achieve that rendering I need to know the path to the current md. if the md is not saved then it would just return standard marked.js rendering. if it is saved (and hence has a path) i will derive some code snippets from the directory and then merge those snippets into the rendering of the markdown.

[borekb]

Markdown processor extensibility would be greatly useful as there is no such things as a single "Markdown" today (just many, many flavors and implementations). I think that ideally, there should be three technical levels of this kind of extensibility:

1. Something like MEF support - you implement a .NET API, compile to DLL, drop to some known location and there you have a new Markdown processor in MP
2. An external process API - if you cannot be a .NET DLL, just create an executable that accepts some well known input (either path or a string with Markdown contents) and return the HTML output. Things like Java implementation could use this, for example.
3. As a last resort, there should be a server support - provide URL / some kind of REST API, accept Markdown text and return HTML

MarkdownPad would ideally support all these three levels, from the most performant one to the least, but also from the most technically restricted to the least. That way, many different system could integrate with MP quite easily and it would really be of great help because currently, what I see in MP preview pane is not what I see on the website when the *.md is eventually processed by our production library.

[evanw]

Excellent feedback, thank you.

[simoncropp]

@borekb to be fair u can "kind of" do pluggable markdown in the current version. with permission from @evanw perhaps we could sync and i could share with you how this is possible

[borekb]

That would be great!

[evanw]

Hold off for now, please, I'll have an official implementation available in the next release.

[evanw]

(I'll send you both a private beta release early.)