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

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

同时,我也正在用 Javascript 实现一个 HTML 转换工具。
9043 次点击
所在节点    Markdown
44 条回复
jakwings
2014-02-10 13:02:06 +08:00
@oott123 大致上兼容吧,带有块级元素的列表项目的 <p> 元素自动方式会有冲突,列表项目之间可以用空白行分隔。除了列表项目和缩进式代码块之外,块级元素之间都用空白行分隔。

PHP Markdown Extra 的表格的确是挺好看,虽然功能比 DokuWiki 的少了一些。唔,看来我要考虑一下放弃合并表格单元的功能了,或者合并两者的功能……=_=
terrance
2014-02-10 13:04:32 +08:00
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/ )。
jakwings
2014-02-10 13:56:46 +08:00
@Tink 这个我可以尝试通过扩展(图片)链接的定义或者直接新增属性表语法来实现。
jakwings
2014-02-10 14:38:33 +08:00
@mytharcher GFM 的庞大社区影响无可厚非了……我想过坚持使用原生 Markdown ,只可惜没有找到语法解析 bug 比较少的 Javascript 写的工具,最多问题的地方就是行内嵌套了,因为这里从来没有标准,也不知道自己从这个所谓的原生 Markdown 转换工具切换到另一个所谓的原生 Markdown 转换工具之间会不会发生什么不愉快的事情。因此我要求语法尽量少产生歧义,而且至少得有个 Javascript 写的转换工具(服务器可以用 NodeJS)。毕竟用得爽才是真道理啊,Markdown 的作者当初设计时这么随意(说不定他已经用得很爽),就不必管他的 Markdown 了。

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

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

定义列表有计划加入,不过我没想过会产生回溯的问题,不知道你提到的讨论具体是怎样的?
mytharcher
2014-02-10 14:59:25 +08:00
@jakwings 不太记得具体细节了,大意应该是“大多数实现都是顺序分析,而冒号形式的dl结构要分析到冒号才能决定之前的元素是不是dt,造成parser效率低下……”。

我记得PHP Markdown Extra的dl也是这个语法,另外他的脚注也不错。
jakwings
2014-02-10 15:19:44 +08:00
@mytharcher 噢,这个啊,我是用正则按顺序轮流匹配,直到找到符合的文本块。Javascript 上的正则往往比单字符循环判断快,其它原生支持正则的编程语言可能也有这个优势吧。我优先考虑 Javascript/NodeJS ,PHP 、Ruby 、Perl 想移植也不困难。C/C++ 的话可能真的比较麻烦。
acgtyrant
2014-02-10 16:12:26 +08:00
我目前對 Markdown 幾乎沒什麼不滿意的,足夠好用。

當然要說遺憾也不是沒有,就是希望對語法高亮支持的代碼種類要儘可能全。
lleon
2014-02-10 19:07:38 +08:00
我就希望所有的格式码都以一个统一的转义符开始,就像C语言的\一样。
jakwings
2014-02-11 11:40:46 +08:00
@acgtyrant 代码高亮可以用其它方法实现,只要能否指示代码类型就可以了。
jakwings
2014-02-11 11:41:41 +08:00
@lleon 那样会严重降低可读性的,其实也不会经常用到特殊格式。
icylogic
2014-02-11 13:27:48 +08:00
@jakwings 下划线__斜成//这个有意思,然后我觉得把+ - *都定义成无序列表也是挺浪费符号的,说不定可以拿来做别的功能。

我看你的文章里已经开始做了,不如放到github上我们提issue这样效率高一点。
xinyidao
2014-02-11 20:22:31 +08:00
能够自动把标点符号由全角转换为半角的选项吗?
md写中文的时候,有的时候就忘记切换成英文的标点符号来写md语法了。

还有to do list 可以弄一个。topmarks那样的
jakwings
2014-02-11 20:49:27 +08:00
@xinyidao 呃,我打算弄国际通用的语法,自动切换符号会令语法匹配的代码更臃肿的……建议使用可定制性高的输入法工具,例如小狼毫/中州韻/鼠鬚管,或者手写输入法。

我的博文还没有更新过呢,正在一边码代码一边想更好的解析方式,TODO 还没有完全定好。
kawaiiushio
2014-02-11 23:45:04 +08:00
铅笔你好
fwee
2014-02-25 02:01:18 +08:00
markdown本来目标就是用起来舒服..不是让你写parser舒服..这个目标已经达到了..个人感觉GFM就已经很满足需求了
jakwings
2014-02-25 02:12:31 +08:00
@fwee 我明白 Parser 不是越容易写越好。

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

我的目标是完成 Javascript 前后端的转换工具,摆脱没有良好标准的 Markdown 。我的转换工具也会提供类似 GFM 的功能选项。具体计划可以看这里:
https://embed.coggle.it/diagram/5307d7a444d6243f76078bbe/ae602abb9b08afe0ea52aa6f58473ece507ea4facabc2253f4eb920f114eab12#structural-blocks
breeswish
2014-02-26 08:11:48 +08:00
@jakwings 靠谱的Javascript Markdown Parser: https://github.com/chjj/marked
jakwings
2014-02-26 09:28:33 +08:00
@breeswish 已用过,还是有不少 bug 的,你翻翻看 issues 就知道了(我也参与过 bug 的讨论 https://github.com/chjj/marked/issues/298 ),而且作者似乎很忙,没多少时间维护代码。我正在写的转换工具就是参考他的代码的。

更何况 Markdown 没有严格标准。有很多规定都是大家自行定的,至今仍争吵不休。另外,斜体只用单个符号 * 或 _ 标记也是挺让人头痛的。长痛不如短痛,我写个新的,更严格的,类似的标记语言,大家要移植就移植。没有创新的话历史问题依旧会折磨更多的人。
fwee
2014-02-26 11:51:14 +08:00
稍微看了你的spec,解析起来并不会简单多少的...

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/99499

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX