我正在正在设计一个 Markdown/kramdown 语言的变种，希望大家提供一些 Markdown 相关的使用问题，例如语法和功能上的。

[jakwings]

我个人的使用问题已经在另一篇文章中说明了：http://blog.likelikeslike.com/posts/2014-02-05/gossip-about-md.html

同时，我也正在用 Javascript 实现一个 HTML 转换工具。

随着语法树的解析代码的设计进度，我也同时在另一篇文章中进行语法的规范工作。欢迎大家来提意见：

http://blog.likelikeslike.com/posts/2014-02-16/syntax-strictdown-draft.html

语法树的代码暂还不想公开探讨，因为我还在纠结中（执着于代码的简洁中）。总之基本功能（除了 HTML 嵌套）已经将近全部实现了，我会继续纠结出结果来的。

表格语法初步设计出来了，语法树也顺利解析了。大家有意见吗？
http://blog.likelikeslike.com/posts/2014-02-16/syntax-strictdown-draft.html#docus-id-16

已经设计完成，GitHub 页面为： https://github.com/jakwings/strictdown
语法快速参考见： http://jakwings.github.io/strictdown/QuickReference.html

忘了说了，转换工具提供了对段落换行的多种处理模式。

[jakwings]

啊，忘了说了，我设计的这个变种，语法上是要求更严格的，尽量去除原生 Markdown 的语法歧义，所以我才真觉得的有必要实现这个变种。

[faceair]

404 ?

[jakwings]

@faceair 抱歉抱歉……我对网络爬虫设的屏蔽规则有一条太夸张了……现在去缓存应该可以访问了。

[oott123]

听说原生的md没有表格…

[jakwings]

@oott123 是的，因为 Markdown 并不是专门针对 HTML 文档而设计的。但是若要转换为 HTML ，没有表格功能多少会有点不便。

DokuWiki 的表格语法我觉得十分好，因为它不要求对齐表格线，也没有设定表格宽度这些不太重要的功能，左中右对齐语法也很简单而不碍眼。

[icylogic]

希望加一个toc支持，table of content。

话说楼主是打算实现一个大而全的语法还是有所侧重？像比较成功的pandoc markdown，gfm这些都是有侧重点的。

[jakwings]

@icylogic 功能上应该是着重于 HTML 转换方面吧，语法设计上更考虑日常写作的可读性，若去除扩展功能，则几乎相当于语法更严格的 Markdown 。另外表格和标题目录应该算作可选扩展功能。

用 Javascript 写的转换工具不考虑自带代码高亮功能，不过会提供自定义高亮措施的选项。也会提供某些扩展功能的开关（例如 HTML 嵌入功能、表格功能、印刷字符转换功能、和文本缩进以及代码尾部空白行有关的偏执模式）。

TOC 支持有点让人纠结呢，肯定要做成带开关的扩展功能的，不知道生成的列表元素要用什么方式包裹，同时包括目录名称比较能令人接受。这个支持必定会涉及标题的链接中转位置，标题目录是否要带数字前缀的选项，是否允许用户提供自定义 HTML 生成函数。

当然我希望越全越好，只要是利于普遍的日常写作。功能只考虑那些可读性比较好的，扩展功能除了 kramdown 介绍的部分功能以及 TOC 之外，我想不会有其它更常用的功能了吧。

我用 Javascript 写的转换工具是借鉴 GitHub 的 marked 和 markdown-js 的，想要自行修改或扩展应该会挺方便的。

我不知道这个变种以后会不会流行呢，总之我会搞定那个 Javascript 语言写的 HTML 转换工具的，至少能用于前端或后端的 Javascript ，摆脱语法不够严谨且功能过少的原生 Markdown 。

[hkongm]

公司程序员一百多号人，除了自己没看到有谁用MD，还都在用WORD和记事本。。。这东西始终小众啊

[jakwings]

@hkongm 没关系，那些经常写（技术）博客或将要编写 MD 相关的软件的人用得着就行了～ reStructuredText 更小众啊，不过已经帮助我分享了上百篇文章了～

[chenlong451]

要良好支持表格，表格要漂亮点。
写API文档时很需要表格。

[jakwings]

@chenlong451 你觉得 DokuWiki 的表格语法怎么样？https://www.dokuwiki.org/wiki:syntax#tables

[terrance]

你需要考虑语法、解析器、编辑器三个部分
目前语法是有点乱，主要流派有gfm，mmd，pandoc
解析器有一大把，几个比较有意思的有：pagedown，pegdown，pandoc，其中pandoc用Haskell写的
编辑器如Mou、stackedit等，分离线和在线

我认为如果要改变目前的生态，首先你要利用好目前的这些工具，其次要做一个令人信服的test suit，另外目前的离线编辑器对markdown的原生功能支持还是太弱了，譬如表格编辑，图片插入等。

我认为比较好的发展方向：用pandoc的子集做一个严格的语法规范，并建立test suit。在此之上做一个离线编辑器，参考emacs的orgtbl-mode实现表格编辑功能，参考Ghost实现图片插入功能。

[RIcter]

Github style的markdown很棒，如果能扩展成那样并且出Python的package就更好w

[znx5858]

想提一个段前缩进，但是这应该属于样式的- -

[jakwings]

@terrance 其实我还没有这么大的目标呢。我不是很擅长编写解释器和转换工具，目前借鉴 marked 这个 Markdown 转换工具的代码，能够达到日常写作的用途是我的基本目标了，编辑器倒没有大的要求，尽量采用一种方便普通文本编辑工具的表格语法（目前看好 DokuWiki 的表格语法）。

我希望定好规范，弄好 Javascript 写的转换工具后有人能够移植或者帮忙改进算法。我有在编写 Javascript 解释工具时考虑严格带来的好处和坏处，相信好处是更多的。目前我是用正则表达式来匹配各种元素的，因为浏览器上的正则貌似比纯粹的字符循环快很多。

我对其它编程语言不怎么熟悉呢，可能没有精力去继续编写维护其它语言的工具了。不过我会尝试将这个变种应用到我以后的网页应用上的。

[jakwings]

@znx5858 CSS 用 text-indent 可以实现，只是列表元素可能要添加一些额外设定。可以参考我的博客。

[jakwings]

@RIcter 不知道 GFM 的哪些语法比较吸引你？如果是表格语法，可以和 DokuWiki 的比较一下：

https://www.dokuwiki.org/wiki:syntax#tables

[chenlong451]

@jakwings 还好。无论什么语法，描述表格总是麻烦些。倒不如直接用html来的直接。

[oott123]

@jakwings 我比较喜欢php markdown extra那个表格语法…怎么说呢，感觉写在编辑器里一看就知道是表格，毕竟markdown是一个机器和人都可以读的~
另外也就是说你这个工具和原生的markdown是兼容的？

[Tink]

需要一个能调整图片大小的参数

[jakwings]

@oott123 大致上兼容吧，带有块级元素的列表项目的 <p> 元素自动方式会有冲突，列表项目之间可以用空白行分隔。除了列表项目和缩进式代码块之外，块级元素之间都用空白行分隔。

PHP Markdown Extra 的表格的确是挺好看，虽然功能比 DokuWiki 的少了一些。唔，看来我要考虑一下放弃合并表格单元的功能了，或者合并两者的功能……=_=

[terrance]

@jakwings 那你可以参考一下pagedown吧
https://github.com/ujifgc/pagedown
https://github.com/jmcmanus/pagedown-extra
https://github.com/benweet/stackedit

[mytharcher]

关于DokuWiki，其实我是早于Markdown接触他的，但是认识Markdown以后立马觉得DokuWiki各种不舒服，估计主要是标题部分很不爽，因为头几级的Header更常用，但却要打更多的=，不如Markdown的方便，另外代码块不如Markdown简单。不过也有几个优点，比如有脚注写法，双符号的行内文本样式比Markdown的更少引起歧义，比如**加重**，__下划线__等。

表格方面PHP Markdown Extra的基本也够用了，DokuWiki也差不多，反正写起来都很麻烦。

行内元素我觉得应该加入减号代表的--删除线--，以尽量减少HTML标签的使用。

另外最好加入定义列表<dl><dt></dt><dd></dd></dl>的格式写法，DokuWiki有个插件是用换行的冒号表示的：

Definition itle
: Definition content

这个功能在Markdown的邮件组讨论过，部分人认为要造成回溯分析导致parse效率降低。

其他的实际上新造一种语法对众多使用者的普遍意义并不大，因为Markdown的世界已经够混乱的了。我曾订阅过Markdown的邮件组，很多老外们的讨论简直旷日持久争执不下，最后都不了了之（之前我发过一个too naive的讨论： http://six.pairlist.net/pipermail/markdown-discuss/2012-May/thread.html ）。原因在于Markdown的作者消失了，然后各个实现的作者又扩展了各自不同的功能，导致每个地方用的都不一样，最后兼容性和可迁移性基本没有（使用了特殊扩展的，其实gfm也是）。最后近两年受到认可且成为主导的居然是传播影响最广的gfm。。。

我非常希望有类似W3C的组织来定义Markdown的Spec，可是目前好像没有什么动静（ http://www.w3.org/community/markdown/ ）。

[jakwings]

@Tink 这个我可以尝试通过扩展（图片）链接的定义或者直接新增属性表语法来实现。

[jakwings]

@mytharcher GFM 的庞大社区影响无可厚非了……我想过坚持使用原生 Markdown ，只可惜没有找到语法解析 bug 比较少的 Javascript 写的工具，最多问题的地方就是行内嵌套了，因为这里从来没有标准，也不知道自己从这个所谓的原生 Markdown 转换工具切换到另一个所谓的原生 Markdown 转换工具之间会不会发生什么不愉快的事情。因此我要求语法尽量少产生歧义，而且至少得有个 Javascript 写的转换工具（服务器可以用 NodeJS）。毕竟用得爽才是真道理啊，Markdown 的作者当初设计时这么随意（说不定他已经用得很爽），就不必管他的 Markdown 了。

** 的确比 * 更适合混合文本，这里我也认为不兼容原生 Markdown 会更方便一些。至于下划线和删除线，我提倡分别用 __ 和 ~~ ，-- 会不利用提供将其转换为 &ndash; (—) 的扩展功能。斜体可以用 // 。行内语法我觉得不接受嵌套会比较好，可以保持可读性。

DokuWiki 的脚注语法其实并不好，会降低可读性，kramdown 的更好。

定义列表有计划加入，不过我没想过会产生回溯的问题，不知道你提到的讨论具体是怎样的？

[mytharcher]

@jakwings 不太记得具体细节了，大意应该是“大多数实现都是顺序分析，而冒号形式的dl结构要分析到冒号才能决定之前的元素是不是dt，造成parser效率低下……”。

我记得PHP Markdown Extra的dl也是这个语法，另外他的脚注也不错。

[jakwings]

@mytharcher 噢，这个啊，我是用正则按顺序轮流匹配，直到找到符合的文本块。Javascript 上的正则往往比单字符循环判断快，其它原生支持正则的编程语言可能也有这个优势吧。我优先考虑 Javascript/NodeJS ，PHP 、Ruby 、Perl 想移植也不困难。C/C++ 的话可能真的比较麻烦。

[acgtyrant]

我目前對 Markdown 幾乎沒什麼不滿意的，足夠好用。

當然要說遺憾也不是沒有，就是希望對語法高亮支持的代碼種類要儘可能全。

[lleon]

我就希望所有的格式码都以一个统一的转义符开始，就像C语言的\一样。

[jakwings]

@acgtyrant 代码高亮可以用其它方法实现，只要能否指示代码类型就可以了。

[jakwings]

@lleon 那样会严重降低可读性的，其实也不会经常用到特殊格式。

[icylogic]

@jakwings 下划线__斜成//这个有意思，然后我觉得把+ - *都定义成无序列表也是挺浪费符号的，说不定可以拿来做别的功能。

我看你的文章里已经开始做了，不如放到github上我们提issue这样效率高一点。

[xinyidao]

能够自动把标点符号由全角转换为半角的选项吗?
md写中文的时候，有的时候就忘记切换成英文的标点符号来写md语法了。

还有to do list 可以弄一个。topmarks那样的

[jakwings]

@xinyidao 呃，我打算弄国际通用的语法，自动切换符号会令语法匹配的代码更臃肿的……建议使用可定制性高的输入法工具，例如小狼毫/中州韻/鼠鬚管，或者手写输入法。

我的博文还没有更新过呢，正在一边码代码一边想更好的解析方式，TODO 还没有完全定好。

[kawaiiushio]

铅笔你好

[fwee]

markdown本来目标就是用起来舒服..不是让你写parser舒服..这个目标已经达到了..个人感觉GFM就已经很满足需求了

[jakwings]

@fwee 我明白 Parser 不是越容易写越好。

再舒服也不希望自己把源代码写得一塌糊涂吧？我的 Parser 写得既舒服，也不会对文章的编写造成多少影响。我目前写的语法说明草稿不是面向初学者的，读起来可能比较难理解。

我的目标是完成 Javascript 前后端的转换工具，摆脱没有良好标准的 Markdown 。我的转换工具也会提供类似 GFM 的功能选项。具体计划可以看这里：
https://embed.coggle.it/diagram/5307d7a444d6243f76078bbe/ae602abb9b08afe0ea52aa6f58473ece507ea4facabc2253f4eb920f114eab12#structural-blocks

[breeswish]

@jakwings 靠谱的Javascript Markdown Parser: https://github.com/chjj/marked

[jakwings]

@breeswish 已用过，还是有不少 bug 的，你翻翻看 issues 就知道了（我也参与过 bug 的讨论 https://github.com/chjj/marked/issues/298 ），而且作者似乎很忙，没多少时间维护代码。我正在写的转换工具就是参考他的代码的。

更何况 Markdown 没有严格标准。有很多规定都是大家自行定的，至今仍争吵不休。另外，斜体只用单个符号 * 或 _ 标记也是挺让人头痛的。长痛不如短痛，我写个新的，更严格的，类似的标记语言，大家要移植就移植。没有创新的话历史问题依旧会折磨更多的人。

[fwee]

稍微看了你的spec，解析起来并不会简单多少的...

[jakwings]

@fwee 的确有不少要注意的地方，不过代码已经够少够简单了。我介绍了的语法都已经能够正确产生解释树了。倒是没人帮忙给一些语法上的建议，我得自己思来想去的。

目前有三种语法还没仔细思考：raw HTML block, inline HTML block, 图片链接定义（不知道该用什么方法指定图片尺寸比较好，甚至指示图片类型）

[jakwings]

@icylogic 大致上设计完毕了，GitHub 页面： https://github.com/jakwings/strictdown

[zealinux]

如果可以，大侠，你试试Orgmode的语法吧。
实现了，那就是功在当代，利在千秋。

[jakwings]

@zealinux 我不用 Emacs 的，之前也只是简单地看了下 OrgMode 的官方文档，是很依赖折叠效果的语法，功能也很杂，不是为了写普通文章而设计的语法，感觉它永远离不开好的编辑工具了。那种既小众又过度依赖编辑工具的语法实在是对它无语。