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

[jakwings]

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

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

[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，解析起来并不会简单多少的...