› Daring Fireball: Markdown
› CommonMark
› MacDown Open Source Markdown Editor
› Marked
› GitHub Flavored Markdown
我正在正在设计一个 Markdown/kramdown 语言的变种，希望大家提供一些 Markdown 相关的使用问题，例如语法和功能上的。
jakwings · 2014-02-09 23:29:01 +08:00 · 9009 次点击这是一个创建于 3941 天前的主题，其中的信息可能已经有所发展或是发生改变。
我个人的使用问题已经在另一篇文章中说明了：http://blog.likelikeslike.com/posts/2014-02-05/gossip-about-md.html
同时，我也正在用 Javascript 实现一个 HTML 转换工具。
同时，我也正在用 Javascript 实现一个 HTML 转换工具。
第 1 条附言 · 2014-02-19 00:06:57 +08:00
随着语法树的解析代码的设计进度，我也同时在另一篇文章中进行语法的规范工作。欢迎大家来提意见：
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
语法树的代码暂还不想公开探讨，因为我还在纠结中（执着于代码的简洁中）。总之基本功能（除了 HTML 嵌套）已经将近全部实现了，我会继续纠结出结果来的。
第 2 条附言 · 2014-02-25 01:20:05 +08:00
表格语法初步设计出来了，语法树也顺利解析了。大家有意见吗？
http://blog.likelikeslike.com/posts/2014-02-16/syntax-strictdown-draft.html#docus-id-16
http://blog.likelikeslike.com/posts/2014-02-16/syntax-strictdown-draft.html#docus-id-16
第 3 条附言 · 2014-03-12 08:50:55 +08:00
已经设计完成，GitHub 页面为： https://github.com/jakwings/strictdown
语法快速参考见： http://jakwings.github.io/strictdown/QuickReference.html
语法快速参考见： http://jakwings.github.io/strictdown/QuickReference.html
第 4 条附言 · 2014-03-12 20:19:11 +08:00
忘了说了，转换工具提供了对段落换行的多种处理模式。
 |
1
jakwings OP  1
啊，忘了说了，我设计的这个变种，语法上是要求更严格的，尽量去除原生 Markdown 的语法歧义，所以我才真觉得的有必要实现这个变种。
|
 |
2
faceair 2014-02-10 00:01:05 +08:00
404 ?
|
 |
4
oott123 2014-02-10 00:46:42 +08:00 via Android
听说原生的md没有表格…
|
|
5
jakwings OP @oott123 是的，因为 Markdown 并不是专门针对 HTML 文档而设计的。但是若要转换为 HTML ，没有表格功能多少会有点不便。
DokuWiki 的表格语法我觉得十分好，因为它不要求对齐表格线，也没有设定表格宽度这些不太重要的功能，左中右对齐语法也很简单而不碍眼。 |
 |
6
icylogic 2014-02-10 01:40:23 +08:00 via iPad
希望加一个toc支持，table of content。
话说楼主是打算实现一个大而全的语法还是有所侧重？像比较成功的pandoc markdown，gfm这些都是有侧重点的。 |
|
7
jakwings OP @icylogic 功能上应该是着重于 HTML 转换方面吧，语法设计上更考虑日常写作的可读性，若去除扩展功能，则几乎相当于语法更严格的 Markdown 。另外表格和标题目录应该算作可选扩展功能。
用 Javascript 写的转换工具不考虑自带代码高亮功能，不过会提供自定义高亮措施的选项。也会提供某些扩展功能的开关（例如 HTML 嵌入功能、表格功能、印刷字符转换功能、和文本缩进以及代码尾部空白行有关的偏执模式）。 TOC 支持有点让人纠结呢，肯定要做成带开关的扩展功能的，不知道生成的列表元素要用什么方式包裹，同时包括目录名称比较能令人接受。这个支持必定会涉及标题的链接中转位置，标题目录是否要带数字前缀的选项，是否允许用户提供自定义 HTML 生成函数。 当然我希望越全越好，只要是利于普遍的日常写作。功能只考虑那些可读性比较好的，扩展功能除了 kramdown 介绍的部分功能以及 TOC 之外，我想不会有其它更常用的功能了吧。 我用 Javascript 写的转换工具是借鉴 GitHub 的 marked 和 markdown-js 的，想要自行修改或扩展应该会挺方便的。 我不知道这个变种以后会不会流行呢，总之我会搞定那个 Javascript 语言写的 HTML 转换工具的，至少能用于前端或后端的 Javascript ，摆脱语法不够严谨且功能过少的原生 Markdown 。 |
 |
8
hkongm 2014-02-10 08:26:36 +08:00
公司程序员一百多号人，除了自己没看到有谁用MD，还都在用WORD和记事本。。。这东西始终小众啊
|
|
9
jakwings OP @hkongm 没关系，那些经常写（技术）博客或将要编写 MD 相关的软件的人用得着就行了～ reStructuredText 更小众啊，不过已经帮助我分享了上百篇文章了～
|
 |
10
chenlong451 2014-02-10 08:44:46 +08:00
要良好支持表格，表格要漂亮点。
写API文档时很需要表格。 |
|
11
jakwings OP @chenlong451 你觉得 DokuWiki 的表格语法怎么样？https://www.dokuwiki.org/wiki:syntax#tables
|
 |
12
terrance 2014-02-10 09:23:02 +08:00
你需要考虑语法、解析器、编辑器三个部分
目前语法是有点乱，主要流派有gfm，mmd，pandoc 解析器有一大把，几个比较有意思的有：pagedown，pegdown，pandoc，其中pandoc用Haskell写的 编辑器如Mou、stackedit等，分离线和在线 我认为如果要改变目前的生态，首先你要利用好目前的这些工具，其次要做一个令人信服的test suit，另外目前的离线编辑器对markdown的原生功能支持还是太弱了，譬如表格编辑，图片插入等。 我认为比较好的发展方向：用pandoc的子集做一个严格的语法规范，并建立test suit。在此之上做一个离线编辑器，参考emacs的orgtbl-mode实现表格编辑功能，参考Ghost实现图片插入功能。 |
 |
13
RIcter 2014-02-10 09:32:21 +08:00
Github style的markdown很棒，如果能扩展成那样并且出Python的package就更好w
|
 |
14
znx5858 2014-02-10 10:48:03 +08:00
想提一个段前缩进，但是这应该属于样式的- -
|
|
15
jakwings OP @terrance 其实我还没有这么大的目标呢。我不是很擅长编写解释器和转换工具，目前借鉴 marked 这个 Markdown 转换工具的代码，能够达到日常写作的用途是我的基本目标了，编辑器倒没有大的要求，尽量采用一种方便普通文本编辑工具的表格语法（目前看好 DokuWiki 的表格语法）。
我希望定好规范，弄好 Javascript 写的转换工具后有人能够移植或者帮忙改进算法。我有在编写 Javascript 解释工具时考虑严格带来的好处和坏处，相信好处是更多的。目前我是用正则表达式来匹配各种元素的，因为浏览器上的正则貌似比纯粹的字符循环快很多。 我对其它编程语言不怎么熟悉呢，可能没有精力去继续编写维护其它语言的工具了。不过我会尝试将这个变种应用到我以后的网页应用上的。 |
|
16
jakwings OP @znx5858 CSS 用 text-indent 可以实现，只是列表元素可能要添加一些额外设定。可以参考我的博客。
|
|
17
jakwings OP |
|
18
chenlong451 2014-02-10 12:27:11 +08:00
@jakwings 还好。无论什么语法，描述表格总是麻烦些。倒不如直接用html来的直接。
|
|
19
oott123 2014-02-10 12:34:07 +08:00 via Android
@jakwings 我比较喜欢php markdown extra那个表格语法…怎么说呢，感觉写在编辑器里一看就知道是表格，毕竟markdown是一个机器和人都可以读的~
另外也就是说你这个工具和原生的markdown是兼容的？ |
 |
20
Tink 2014-02-10 12:51:10 +08:00 via Android
需要一个能调整图片大小的参数
|
|
21
jakwings OP @oott123 大致上兼容吧，带有块级元素的列表项目的 <p> 元素自动方式会有冲突，列表项目之间可以用空白行分隔。除了列表项目和缩进式代码块之外，块级元素之间都用空白行分隔。
PHP Markdown Extra 的表格的确是挺好看，虽然功能比 DokuWiki 的少了一些。唔，看来我要考虑一下放弃合并表格单元的功能了，或者合并两者的功能……=_= |
|
22
terrance 2014-02-10 13:04:32 +08:00 1
|
 |
23
mytharcher 2014-02-10 13:11:24 +08:00
关于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/ ）。 |
|
25
jakwings OP 1
@mytharcher GFM 的庞大社区影响无可厚非了……我想过坚持使用原生 Markdown ，只可惜没有找到语法解析 bug 比较少的 Javascript 写的工具，最多问题的地方就是行内嵌套了，因为这里从来没有标准，也不知道自己从这个所谓的原生 Markdown 转换工具切换到另一个所谓的原生 Markdown 转换工具之间会不会发生什么不愉快的事情。因此我要求语法尽量少产生歧义，而且至少得有个 Javascript 写的转换工具（服务器可以用 NodeJS）。毕竟用得爽才是真道理啊，Markdown 的作者当初设计时这么随意（说不定他已经用得很爽），就不必管他的 Markdown 了。
** 的确比 * 更适合混合文本，这里我也认为不兼容原生 Markdown 会更方便一些。至于下划线和删除线，我提倡分别用 __ 和 ~~ ，-- 会不利用提供将其转换为 – (—) 的扩展功能。斜体可以用 // 。行内语法我觉得不接受嵌套会比较好，可以保持可读性。 DokuWiki 的脚注语法其实并不好，会降低可读性，kramdown 的更好。 定义列表有计划加入，不过我没想过会产生回溯的问题，不知道你提到的讨论具体是怎样的？ |
|
26
mytharcher 2014-02-10 14:59:25 +08:00
@jakwings 不太记得具体细节了，大意应该是“大多数实现都是顺序分析，而冒号形式的dl结构要分析到冒号才能决定之前的元素是不是dt，造成parser效率低下……”。
我记得PHP Markdown Extra的dl也是这个语法，另外他的脚注也不错。 |
|
27
jakwings OP @mytharcher 噢，这个啊，我是用正则按顺序轮流匹配，直到找到符合的文本块。Javascript 上的正则往往比单字符循环判断快，其它原生支持正则的编程语言可能也有这个优势吧。我优先考虑 Javascript/NodeJS ，PHP 、Ruby 、Perl 想移植也不困难。C/C++ 的话可能真的比较麻烦。
|
 |
28
acgtyrant 2014-02-10 16:12:26 +08:00
我目前對 Markdown 幾乎沒什麼不滿意的，足夠好用。
當然要說遺憾也不是沒有，就是希望對語法高亮支持的代碼種類要儘可能全。 |
 |
29
lleon 2014-02-10 19:07:38 +08:00 via Android
我就希望所有的格式码都以一个统一的转义符开始，就像C语言的\一样。
|
|
32
icylogic 2014-02-11 13:27:48 +08:00 via iPad
@jakwings 下划线__斜成//这个有意思，然后我觉得把+ - *都定义成无序列表也是挺浪费符号的，说不定可以拿来做别的功能。
我看你的文章里已经开始做了，不如放到github上我们提issue这样效率高一点。 |
 |
33
xinyidao 2014-02-11 20:22:31 +08:00
能够自动把标点符号由全角转换为半角的选项吗?
md写中文的时候，有的时候就忘记切换成英文的标点符号来写md语法了。 还有to do list 可以弄一个。topmarks那样的 |
|
34
jakwings OP @xinyidao 呃，我打算弄国际通用的语法，自动切换符号会令语法匹配的代码更臃肿的……建议使用可定制性高的输入法工具，例如小狼毫/中州韻/鼠鬚管，或者手写输入法。
我的博文还没有更新过呢，正在一边码代码一边想更好的解析方式，TODO 还没有完全定好。 |
 |
35
kawaiiushio 2014-02-11 23:45:04 +08:00
铅笔你好
|
 |
36
fwee 2014-02-25 02:01:18 +08:00
markdown本来目标就是用起来舒服..不是让你写parser舒服..这个目标已经达到了..个人感觉GFM就已经很满足需求了
|
|
37
jakwings OP @fwee 我明白 Parser 不是越容易写越好。
再舒服也不希望自己把源代码写得一塌糊涂吧？我的 Parser 写得既舒服，也不会对文章的编写造成多少影响。我目前写的语法说明草稿不是面向初学者的，读起来可能比较难理解。 我的目标是完成 Javascript 前后端的转换工具，摆脱没有良好标准的 Markdown 。我的转换工具也会提供类似 GFM 的功能选项。具体计划可以看这里： https://embed.coggle.it/diagram/5307d7a444d6243f76078bbe/ae602abb9b08afe0ea52aa6f58473ece507ea4facabc2253f4eb920f114eab12#structural-blocks |
 |
38
breeswish 2014-02-26 08:11:48 +08:00
@jakwings 靠谱的Javascript Markdown Parser: https://github.com/chjj/marked
|
|
39
jakwings OP @breeswish 已用过，还是有不少 bug 的，你翻翻看 issues 就知道了（我也参与过 bug 的讨论 https://github.com/chjj/marked/issues/298 ），而且作者似乎很忙，没多少时间维护代码。我正在写的转换工具就是参考他的代码的。
更何况 Markdown 没有严格标准。有很多规定都是大家自行定的，至今仍争吵不休。另外，斜体只用单个符号 * 或 _ 标记也是挺让人头痛的。长痛不如短痛，我写个新的，更严格的，类似的标记语言，大家要移植就移植。没有创新的话历史问题依旧会折磨更多的人。 |
|
40
fwee 2014-02-26 11:51:14 +08:00
稍微看了你的spec，解析起来并不会简单多少的...
|
|
41
jakwings OP @fwee 的确有不少要注意的地方，不过代码已经够少够简单了。我介绍了的语法都已经能够正确产生解释树了。倒是没人帮忙给一些语法上的建议，我得自己思来想去的。
目前有三种语法还没仔细思考：raw HTML block, inline HTML block, 图片链接定义（不知道该用什么方法指定图片尺寸比较好，甚至指示图片类型） |
|
42
jakwings OP @icylogic 大致上设计完毕了，GitHub 页面： https://github.com/jakwings/strictdown
|
 |
43
zealinux 2014-03-12 10:21:53 +08:00
如果可以，大侠，你试试Orgmode的语法吧。
实现了，那就是功在当代，利在千秋。 |
Select Language