the future of markdown, according to jeff atwood (and/or david greenspan)

[Fletcher Penney]

On Oct 25, 2012, at 11:37 PM, Sherwood Botsford wrote:


> I agree.  Since M. Gruber will neither document the fringe cases, nor take on any role in the continueing development, the torch needs to pass to another.


Just to be clear - Markdown (both the perl script and the "name") are Gruber's.  They cannot be passed to another without his permission.

Moving on....


In my ideal world, Gruber would reengage with the Markdown community to actually clarify some of the edge cases/inconsistencies that still exist (not just to claim that there are no inconsistencies), and at least add footnotes to the syntax (I get that he doesn't want anything else, but the footnote proposal was his initially....)  

Perhaps he would even endorse a formal grammar specification and/or complete test suite.  This wouldn't be that much work (especially if he got some help), and would go a long way towards ensuring the continued survival of the Markdown brand, which will otherwise continue to remain under threat of something better/more consistent coming along.

IF this were to happen, I am not sure that I would see the value in creating a new syntax, and we could all just stick with Markdown.  This would be **much** less confusing for users, and would help keep Markdown's "mindshare" high.

The next best thing would a "descendent" to Markdown that shares the same spirit but is actively maintained.  This is not as good as option A in my opinion.  But if A won't happen, then is option B better than nothing?  The challenge, however, would be getting multiple developers (who are generally happy with their own implementation) to go through the effort to move to a new core syntax (e.g. Rockdown or whatever ---- as an aside, please choose a different name....).  This has been the stumbling block when this proposal has come up before (both on this list and in emails between several developers with their own Markdown derivatives).  

For example, I am generally happy with MultiMarkdown.  What do I gain from rewriting it to match "Rockdown" instead of trying to match Markdown?  If only 50% of developers make the switch, what have we accomplished?   If the Markdown community gets split between Markdown and Rockdown, does that just make something else (e.g. reStructuredText, Textile) a more attractive alternative?  These things need to be considered before moving too far along.


> I would add a couple point to your proposal:

> 

> 6.  The initial version should be bug compatible with Gruber's MD, possibly using a command line flag.  That is Rockdown --original should produce the exact same HTML as GMD on the test suite.

> 

> This allows users to drop it in as a replacement, and handle the exceptions one by one.


I'm not sure I follow the logic of intentionally creating bugs just for the sake of mimicking the very implementation we are trying to clean up.  If the new project is not blessed by Gruber, by definition it will be a new syntax/brand.  Why intentionally make it buggy?


> As a seventh point there may be merit in putting in some way to add extension modules.  This way the can (hopefully) be common development on the core of NarkDown (comes after Markdown.  The next one would be ParkDown) while individual authors integrate multiple formats, different conventions, and so on.



As I, and others, have proposed multiple times on this list before, this would be a necessity in some fashion.  I think there should be three "levels" of extensions/modules:

* The core set --- e.g. basically everything Markdown does now, with the possible addition of footnotes.  All implementations *must* include these to use the "FOO" brand.

* The "blessed" extensions --- things that basically everyone agrees should be in the core feature set but aren't (e.g. footnotes if not included above, and maybe one or two other features.)  This set should be limited, and thoroughly vetted (feature bloat is a tempting, but dangerous, thing).  The key, however, is that these features need to be implemented the same way across those implementations that support them.  By implementing all of these, a given variant could use the "FOO+" brand, or whatever.

* Optional features --- these are the additions that individual variants include to scratch an author's own itch and are not uniformly agreed upon (e.g. tables, bibliographic citations, math, etc.)  There could be a process to move features to the "blessed" set if they gain enough support amongst the community.  Developers would not be required to include these or to implement them in the same way across variants.  But it would be nice to centralize the information so that one can choose to be consistent, if desired.


My $.02,


FTP


-- 
Fletcher T. Penney
fletcher at fletcherpenney.net