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

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

404 ?

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

听说原生的md没有表格…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于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/ ）。

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

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

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

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

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

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

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

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

我目前 Markdown 乎什不意的，足好用。

然要憾也不是有，就是希望法高亮支持的代要可能全。

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

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

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

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

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

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

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

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

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

铅笔你好

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

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

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

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

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

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

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

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

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

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

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

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

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