For some projects of mine, I wanted a lightweight C library that can parse John Gruber's markdown format into whatever I want, and that is easily extendable.
The only C implementations of markdown that I know of are Discount and PEG-markdown. Discount seemed a little bit too integrated and focused on HTML output for my taste, and PEG-markdown seemed to have a lot of dependencies and stuff. So I wrote my own.
I like to keep things simple, so I wrote a function that performs only markdown parsing: no file reading or writing, no (X)HTML considerations, etc. The actual output is performed by a set of dedicated callback functions, called here a renderer. Some example renderers are provided, but you are free to use your own to output in any format you like.
This callback mechanism make libupskirt so flexible that it does not need any flag or external information besides input text and renderer to operate.
The code almost completely feels my needs and those of users I know of, so I consider the project as being mature. I will of course fix bugs that are discovered, and will consider feature requests, but don't expect much changes at this point.
There has been a lot of discussion about how offensive the name of the project used to be. So I wrote how it ended up having such a name. Eventually I renamed it to the more neutral and thematically-consistent name it currently has.
I often wonder why people feel the need to fork code instead of collaborating to it, sometimes even without letting a chance for people in the original project to know. Anyways, here is the list of the publicly-available forks that I know of:
It seems to be a fork from a repository that was already obsolete by then, and a bugfix that had been already available in the main repository for a long while. As of end of May 2011, this repository was last updated in December 2010.
It got a lot popularity due to being used in production by GitHub. While sharing the same initial code base, this fork is wildly different from my project in terms of philosophy, design and intended use.
Before it stopped mentioning my original project, it was described by its author as being more “for the web” and mine as being more “UNIX-y”; I don't feel qualified to judge that point so I'll just quote them on this.
My opinion is that there are two major philosophical differences from which all the actual divergences stem:
- my library is meant to be only a parser, with the rendering being left to the client/user, and the provided renderers are only meant to be examples. On the other hand, GitHub's fork seems to be meant for stand-alone Markdown-to-(X)HTML. The main consequence is that parser and renderer are much more tightly coupled together, through a more complex and more changing interface.
- GitHub's fork emphasizes features, which means more changing code, sometimes organically growing, while risking featuritis and instability. On the other hand my project emphasizes design, which means a slower pace, less features built in the parser (I'm gambling on the fact that renderer flexibility is enough to compensate for it), leading to more consistency, robustness and stability, while risking sclerosis and lack of trendiness.