我设计了一种文本标记格式，用来代替 Markdown 格式。请大家一定来夸我，或者拍砖：）

@Livid 有没有兴趣在 V2EX 支持这种文本标记格式？如果有的话，我们现在还需要给它起一个可爱的名字并写一个能把它转换为 HTML 的翻译器。

这能比 markdown 好读？还没有编译器？
楼主不要总想搞个大新闻出来。

把()换[]就好了，方便输入

(img src=|photo.jpg| width=|60px| height=|40px|)

<img src="photo.jpg" width="60px" height="40px" >

我觉得我还不如用 jade 去……

@oott123 Jade http://jade-lang.com/ 使用的是基于空格的语法，有时候多一个或少一个空格就会导致错误结果与预期不同。 Jade 很有用，但有些人觉得它的语法比较脆弱，我设计的语法没有这个问题。

可能比较先入为主,但是我还是觉得 html 的 xml 类文本比较适合编写

补充一个特性：

我设计的语法支持在插入的代码里面再进行对部分字符添加格式。

由于评论里不能保存空格，我把这个例子贴在这里了： http://v2ex.com/t/255292

@ragnaroks 是的，因为 Markdown 的表达力很有限，好多时候比如插入图片，还不如直接用 HTML 。我们设计的语法与 HTML 在表达力上是完全等价的。有的时候还能少敲几个字符。

HTML ：

<p>这个句子里有<i>斜体</i>字。</p>

新语法：

(p . 这个句子里有(i . 斜体)字。)

好难读啊

@bitbegin 谢谢。我有考虑过使用 [ 和 ]，但有一个顾虑就是由于使用了 | 来表示一个字符串，而 | ] 放在一起可能会引起混淆，所以决定还是使用 ( ) 。

为什么使用 | | 来表示字符串而不是 "" 或 ''？这是因为 (p . xxx) 中“.”后面的内容里面很可能会出现 " 或 '，所以有可能产生视觉上的混淆，而 | 又是使用频率相对少的字符，所以使用它来表示字符串。

table 要怎么玩? 会不会嵌套太多, 头大

和直接用 HTML 没什么区别，就是少敲些字符而已。 Markdown 的优势在于让你写作时更专注内容而非格式，而且原始格式即便不经过转化也能体现基本的「视觉效果」

@bdbai @Tink 是否好读是主观的，我觉得挺好读的，但这都不是大事儿。重要的是我们不能把“形状上更直观对称”（比如 Markdown 的 ** hello ** 相对于王婆今天想卖的新语法的 (strong . hello) ）等同于好理解、容易被头脑翻译。

王婆今天想卖的新语法的一个很大的优点是它 (strong . 只有一条语法)，这样新手也能很快读懂别人写的文档， Markdown 的语法就很多，至少要学十分钟，而且隔段时间不用忘了，又要再学十分钟；）

万一需要在文档中插入图片，就要使用 Markdown 的如下语法：


与 Markdown 的其他的“好看”的语法规则没有任何一致性。而在新语法中，只有一中形势：

(img alt-text=|alt text| src=|http://www.v2ex.com/path/to/img.jpg|)

Markdown 的优势就是简单到几乎不破坏内容。你这个格式有些复杂了，为什么不 XML 呢

这样的话，为什么不直接 html 呢

其实我认为更像是一个 HTML 的改进版（或者说…查找替换版），而和 markdown 不沾边…

@yinheli 谢谢，这是一个好问题。关于 table ，有两个思路，一个就是直接向 HTML 那样嵌套，由于我们的语法与 XML 能表达相同的语义，所以这么做至少是可行的。

另一个思路就是通过插件的形势来支持其他格式，比如我们可以直接使用 CSV 格式表示 table ，然后自动由插件转换为 HTML 输出。例子：

(table plugin=|csv-paser| .
name, sex, age
Tom, 23, male
Sue, 34, female
)

然后输出是漂亮的 HTML 表格。

@zxgngl 你这个自定义插件的思路倒是和 Haskell 的 Quasiquotation 差不多了。

总的来看我觉得挺有前途的，特别是那个 (@ @) 比较新颖，我之前自己写是让用户随便换 () [] <> {} 但是如果写自己的文档就会傻逼。但是若要替代 Markdown ，你需要加入两个支持，一个是最顶层的文本可以被直接当做段落处理，另一个是 Markdown 那个段内标记，**hello** 什么的。此外，你这个这么贴近 HTML ，你可能需要允许用户重新定义下 **hello** 的语义，所以 parse 完了之后可能还需要个 interpreter 。

我读错了，楼主是专门反 **Markdown** 的这种 ad hoc 的做法啊，不过就连 TeX 都加入了 $1+2$，楼主可能要失望了

@learnshare @yuuko 虽然 XML 的表达能力几乎是不可超越的极限了（我们设计的新语法也达到了这个极限），但 XML 的书写可能会非常复杂，或者不方便。

＊ 我们的新语法中，插入任何代码都是不需要转义的，方便拷贝来、拷贝去，代码内容不会被破坏。

＊新语法中可以对代码进行“再格式”， Markdown 似乎做不到这点。

＊新语法中可以通过 plugin 的方式支持其他的格式，比如 CSV 表格，不需要像 Markdown 那样手动画 ASCII 表格。

＊比 XML 敲的字少。

＊只有一条语法，几个特殊字符，而且绝大多数情况下不会遇到需要转义的情况。

其他的好处让我再想想……

> Jade http://jade-lang.com/ 使用的是基于空格的语法，有时候多一个或少一个空格就会导致错误结果与预期不同。 Jade 很有用，但有些人觉得它的语法比较脆弱，我设计的语法没有这个问题。

那这个说白了就是 不用空格 用 （）的类 jade 标记格式喽？
//LZ 肯定不是 python 用户

不少 JS 的 MVVM 库都在属性里用了竖线“|”啊。。。

@wph95
大概 LZ 做的是一个包装成 Lisp 或者 S 表达式 的 Jade ？
实际上 Markdown 发明的目的是，为了让用户在创作文档的时候不关心最终的格式，而只关心文章的大纲结构和语义。比如说 Markdown 原版是没有定义“下划线”的，也没有定义“加粗”和“斜体”的强制要求：你甚至可以让本应斜体的字用仿宋体来显示。
楼主这套东西或许能让 Lisp 用户基于之上开发一个 Lisp 网站框架（地位相当于 Jade 之于 Node.JS ），和 Markdown 的地位是有区别的。
// LZ 肯定不是 Python 用户
// LZ 有往 Lisp 用户发展的潜能

markdown 的优势是摆脱了 嵌套，因而源文件也有很好的可读性。所以容易编辑、容易传播。
另外给不同元素不同表达形式有利于提高辨识度。

如果一个人真的希望简单地编辑复杂的文本，那他应该用 Office 。

@zxgngl
Markdown 插入图片的语法非常多，不仅仅是一种
http://spec.commonmark.org/0.24/#images 这边有一坨。
我觉得最实用的方法是 Example 548 那个，那种语法只需要在图片名字旁边加一个感叹号就可以了，然后图片的 URL 补充在 *整个文档* 的最后面。
链接也可以这么玩。
这样写就让人有种书籍的脚注的感觉，既不干扰阅读，又方便解析。

Markdown 官方的说法是： It ’ s a plain text format for writing structured documents, based on formatting conventions from email and Usenet.
也就是说 Markdown 很多语法是有历史意义的：三十年前人们就这么写邮件的， Markdown 只是提供了一个标准化而已。

你 revert 了 Markdown 的设计初衷。
Markdown 不是为了功能强大，而是为了简约。要功能强大，有 ubbcode ，也有直接用 HTML 。

这就是走马观花的结果！

总感觉跟 jade 大同小异

虽然语法只有一条, 但是关键字却有 N 个, 比如
`(img src=|photo.jpg| width=|60px| height=|40px|)`
里面就有 img, src, width, height 这么多个关键字, 都是不能修改的, 否则 parser 无法解析, 虽然这些关键字和 HTML 是一致的, 但不是每个人都能把 HTML 的关键字都熟练掌握的, 而 Markdown 就没有这么多关键字要记, 只有那么几个*符合直觉*的语法
做个类比, 按 LZ 的说法, 其实 HTML 也只有一种语法就是<XX>OO</XX>

我觉得 Markdown 的意义在于能在书写过程中可以忽略板式而专注于内容，所以要做到两点：简约和可读
功能不能复杂，专注于内容的同时不被语法本身打乱思路
可读则保证了即使没有对应的解析处理，生 Markdown 的文本一样能够被有效的直接阅读，即使没有 Markdown 语法知识的人也能理解其中的意思，甚至段落也能保持一致。同时，试想下你在写内容的时候如果自己的文本都看着需要绕圈，怎么专注于内容本身？

私以为，既然设计一个产品，先考虑你的目的是什么，为了解决什么问题，和现有的产品有什么区别？
既然是为了替代 Markdown ，你的确解决了 Markdown 的功能不全的问题，但却抛弃了 Markdown 本身核心的极大特点，从根本上其实还是回到了 XML 类语法的设计上，那这和 XML 比又有什么区别呢……

总的来说，我觉得有种重复早轮子的感觉了

真还不如 html 呢、既不专注内容又有一定的学习成本

怎么说呢...
md 插入代码
```
```
你这个

(@code lang=|C++| .

@)

这样的东西跟伟大的 md 相比...没法吐槽啊.

asciidoc 不是更好用，功能强大，还有统一的标准

这个语法设计有点意思

可读性不高呀，其实觉得在 markdown 基础上面多点语法糖就可以了

Github 的 markdown 格式有 strikethrough 的。

前段时间， Slack 也支持这个标记，但原版的标准是没有这个格式的。早就有很多人向 John Gruber 建议，希望标准里加入这个标记。

我记得他的回应是，尽可能地让 markdown 像纯文本一样可读，是 markdown 的首要目标。

楼主是否有把官方标准通读数遍呢？

不讨论语法，从用户体验来说，每打出括号需要多按一个 Ctrl 键， so

@minsheng

(@@quote .
你这个自定义插件的思路倒是和 Haskell 的 Quasiquotation 差不多了。

总的来看我觉得挺有前途的，特别是那个 (@ @) 比较新颖，我之前自己写是让用户随便换 () [] <> {} 但是如果写自己的文档就会傻逼。
@@)

据说佛印说过，心中有佛，就能容易看到佛。这个新语法显然不是什么佛，但你心中显然有佛。谢谢～

建议用[] 方便, 另外代码块的格式易读性和书写感觉并不高

我感觉就是简化的 XML

@ThomasZ

(quote .
建议用[] 方便, 另外代码块的格式易读性和书写感觉并不高
)

考虑过使用 [ 和 ]，但一个顾虑就是由于使用了 | 来表示一个字符串，而 | ] 放在一起可能会引起混淆，所以决定还是使用 ( ) 。

为什么使用 | | 来表示字符串而不是 "" 或 ''？这是因为 (p . xxx) 中“.”后面的内容里面很可能会出现 " 或 '，所以有可能产生视觉上的混淆，而 | 又是使用频率相对少的字符，所以使用它来表示字符串。

@zealic

(quote . 我感觉就是简化的 XML)

是的，在语法上就是简化的 XML ，虽然它相对于 XML 有一个非常大的优点是：插入任何代码都是不需要转义的，方便拷贝来、拷贝去，代码内容不会被破坏。

这个新语法是颠覆性创新吗？肯定不是啊，要是颠覆性创新，至少在语义表达力上要有多突破吧。 XML 已经是语义表达力的极限了，新语法也仅仅是达到了这个极限而已。一个东西有用、好用，不一定非要是颠覆性创新的。

@EugeneQiu 我想你想说的是 Shift 键吧？选择（）而不是［］是有原因的（请参考 42 楼），另外，有那么多快乐的 Lisp 程序员说明按一下 Shift 键并不会影响用户体验。

@Livid

(quote .
创建新回复过程中遇到一些问题：

你回复过于频繁了，请稍等 1800 秒之后再试
)

经常会遇到这种情况，可不可以把阈值调高一点？

这个是 XML 改，跟 Markdown 不搭边吧。

@zxgngl
> 是的，在语法上就是简化的 XML ，虽然它相对于 XML 有一个非常大的优点是：插入任何代码都是不需要转义的，方便拷贝来、拷贝去，代码内容不会被破坏。

你忘了 XML 有个东西叫做 CDATA ？

@zbz

(quote . 可读性不高呀，其实觉得在 markdown 基础上面多点语法糖就可以了)

Markdown 的问题就是语法糖太多了，而且语法之间没有一致性，画个表、插个图，语法就变得非常难写难记。而且一段时间不用 Markdown 后再用它，语法还要从新学一遍。

md 主要是维持了原来人们在邮件列表中习惯了的格式（你在一些文档例如 IETF RFC 里面也能看到类似的格式）。我觉得你应该向 TeX 使用者推销。有时候我觉得 TeX 爱好者挺疯的。

为什么要用 () 而不是 <> 呢？

非 monospace 的字体，<> 应该比 () 易读一些

@zxgngl

> Markdown 的问题就是语法糖太多了，而且语法之间没有一致性

因为 Markdown 的语法是众多网民一起发明的。基于 30 年前的邮件排版格式。

> 画个表、插个图，语法就变得非常难写难记。

参看 26 楼，我可以插一幅 ![泣不成声.jpg] 在这里。
然后到整个文章写完了再补充这个图片的 URL 地址：

脚注：
[泣不成声.jpg] http 什么 www 什么什么.jpg

@StarBrilliant

(quote . 你忘了 XML 有个东西叫做 CDATA ？)

在 XML 里面使用 CDATA ，需要把 “]]>” 这样的字符串转义为“]]]]><![CDATA[>”，这已经很难看了。而且 CDATA 不能嵌套，也不能对 CDATA 里面的内容进行二次格式话。而这些问题在我的新语法里都被解决了。

新语法支持在插入的代码里面再进行对部分字符添加格式。由于评论里不能保存空格，我把这个例子贴在这里了： http://v2ex.com/t/255292

其实 XML 的标准是一本几百页的大部头……
那么问题来了，考虑到楼主的语法就是 XML 的极端简化版，假如要达到它的表达能力，要不要往里面加东西呢？

@zxgngl

迫真认为你的那套东西永远不需要转义似的？
如果我要贴一份所有 2 ASCII 字符组合的清单：
就像这样：
.. AA AB AC AD ... (= (> (? (@ ...
好，挂掉了。

当然你可以狡辩说我可以转义啊。
那就转义： (= (> (? (@ span . ( @) (@ span . @ @) (A 。
好吧，这个转义比 XML 那个还恐怖，还引入了新的 DOM Node 。

当然你会说这种情况出现的非常少啊。

那我请问 XML 里面 CDATA 需要转义的情况有多少？

你可以推广你这套 Markup ，但是永远不能替代 Markdown （或许 Jade ，也或许 TeX ）。
因为 Markdown 可以通过电子邮件传送，你这套 Markup 不行。

Markdown 的特点在于，这个世界上是先有“ Markdown ”，后有 HTML 的。
Markdown 并不依附于 HTML 。现在也有 Markdown 编译到 Microsoft Word 或者 LaTeX 的编译器。

而且， Markdown 并没有定义“加粗”“斜体”“下划线”“删除线”这些东西，这些东西是实现 Markdown 的人认为规定的。
比如，在中文当中，强调是用着重号，而英文当中，强调是用意大利体（ italic ，俗称真斜体）。 Markdown *从来没有规定* 什么符号是表示要用意大利体，而是简单地规定了 * 表示“强调”。
至于强调到底是强调成什么表现，或许是着重号，或许是意大利体，也或许只是读者的脑补（比如读者没安装 MD 阅读器）罢了。

Markdown 贴代码，最早的方案是前面加四个空格，因为 30 年前大家在电子邮件里发代码的时候就是这么做的。后来发现每行前面加空格不方便，大家转用三个 ` 的符号。这只是方便而已。

况且现在的 Markdown 语法已经非常自由了，我几乎随便写，编译器最后都能解析出来，没有什么标准语法。（只要你经常阅读邮件列表，就能自然而然收到 Markdown 文化的薰陶。你说你不读？抱歉，你在远离这个世界上最顶尖的技术大牛所在的地方。）

这个世界上是先有“ Markdown ”，后有 HTML 的。
这个世界上是先有“ Markdown ”，后有 HTML 的。
这个世界上是先有“ Markdown ”，后有 HTML 的。

重要的事情说三遍。

然而你的 Markup 语言一上来就捆绑了 DOM Node 这套，已经不可能替代 Markdown 了。你可以去劝说 Lisp 用户基于你这套东西开发脚本引擎。然而并不能劝说 Markdown 用户放弃这种已经有 30 多年历史的纯文本排版方式。

另外，你知道 UBB Code 是怎么死的么？这语法最早发明是为了安全：让用户手动输入 HTML 不好检查安全性。 UBB Code 之死，并不是因为 [b]这种语法[/b] 太难打了，而是 [i]它是基于 HTML 的，并不能替代 HTML[/i]，以及 UBB 的 [b]加粗[/b] 只能解释成 [b]加粗[/b]，不能解析成任何别的具有强调意义的形式。

@StarBrilliant 我感觉 其实 4 楼真相了

@zxgngl

我很反感你在大家开始普遍接受你的 Markup 语法之前，就使用这种语法来回复人。
这很不尊重。因为语言是给大家能看懂的。

我也可以基于 Brainf*ck 语法来发明一个 Markup 语言，然后用来回复你的帖子，这样真的好吗？
-----[->+++++<]>-.[--->++++<]>+.---------.[++++>-<]>++++.[++>-----<]>+.[--->++++<]>+.--[->+++<]>-.---[->+++<]>.+++++.--[--->+<]>-.+++[->+++<]>+.---.-[--->+<]>-.[->+++<]>.[++>---------<]>.+[->+++<]>.+[->++++<]>.-[--->+<]>.-[++++>-<]>++.[++>-----<]>+.>++[++>-<]>-.[++++>-<]>++++.[++>-----<]>-.-[--->+++++<]>.[++++>-<]>+++.--[->++++<]>+.+[--->++<]>+.[--->+<]>.--[->++++<]>.>+[--->+<]>---.+[--->+<]>.>++[++>-<]>-.++.

@wph95
233333333333 我只是水贴混经验而已 ;-)

你高兴就好

真心是 Markdown 容易读呀，看看 LISP 有多少人用就知道了。

比较一下：

搞个**大**新闻
搞个(b . 大)新闻

问问非程序员哪个更直观

HTML ：
<p>这个句子里有<i>(i . 斜体)</i>字。</p>

用你的新语法怎么搞？

@victor

这样写：

(p .
这个句子里有(@i . (i . 斜体)@)字。
)

@liuxey

(@quote .

(img src=|photo.jpg| width=|60px| height=|40px|)
<img src="photo.jpg" width="60px" height="40px" >

@)

我想，你想说明的是“瞧，你这个设计并没有什么颠覆性创新嘛，和 HTML 没什么不一样的嘛。”是的，这不是颠覆性创新，并不能推翻整个世界：）一个东西有用、好用，不一定非要是颠覆性创新的。另外，你只是看到相思的地方，但没有领会有创新的地方。请看一下 19 楼的留言。

@vanxining 谢谢提醒，我会研究一下 XML 的标准（ https://www.w3.org/TR/REC-xml/ ），看看有什么可以借鉴的～

拙见：思路上和 HTML 一样，语法上比 HTML 简练（类似于 yaml 之于 json 的关系?），但要说代替 Markdown 那还是不够，因为这个思路太复杂了 :-) Markdown 最重要的特色在于可以轻易阅读的源文件，而 HTML 和你的这个正是因为想表达千千万万种东西，所以不具备可以轻易阅读的属性。

@StarBrilliant

(@@quote .
迫真认为你的那套东西永远不需要转义似的？
如果我要贴一份所有 2 ASCII 字符组合的清单：
就像这样：
.. AA AB AC AD ... (= (> (? (@ ...
好，挂掉了。
@@)

我的这套东西真的永远不需要转义的，如果要贴一份所有 2 ASCII 字符组合的清单，这样表示就可以了：

(@@div . .. AA AB AC AD ... (= (> (? (@ ...@@)

好，抗住了。；）

可能，你没有认真看我的说明。在我的语法里，"@"的个数是任意的，只要前后匹配即可。其实我一直没有点出来，但这个设计其实是个比较大的革新，因为它意味着这个语言的 parser 不能是像 Markdown 那样基于正则表达式来设计了。这是因为正则表达式的所能表达的正则语言的表达力其实是有限的。

@StarBrilliant

(quote .
你可以推广你这套 Markup ，但是永远不能替代 Markdown （或许 Jade ，也或许 TeX ）。
)

虽然这句话是对我的脑力劳动成果的某种否定，但我内心和你的看法很像。好东西不一定流行，这个世界就是这样。我们也没啥子办法～

@StarBrilliant

哎呦喂～大爷不要生气，小的应该早点回复这一点的：

> 我很反感你在大家开始普遍接受你的 Markup 语法之前，就使用这种语法来回复人。
这很不尊重。因为语言是给大家能看懂的。

我努力尝试去耐心解答和解释每一个人的问题和质疑，尽可能去吸收每一个思想碰撞的火花，对大家的评论都是认真对待的，从来没有想表达对任何人的不敬。使用自己的 Quote 语法也是想在实用中检验一下，尝试看能否暴露出问题。

如果真的认真读帖的朋友，应该可以在一秒钟内看懂 (quote . 引文)，所以看懂是不难的，所以我觉得是有可行性。另外，大家用什么语法回复我，我都是欣然聆听的。我觉得只要不限制别人一定要用某种东西，大家就能够平等交流。

我不知道用这个帖子里重点讨论的语法回复你会导致你觉得自己不被尊重，向你表示歉意。之后回复你的评论，我会用“>”语法。但是在其他回复中我会继续使用新语法，也欢迎大家也尝试使用新语法，目的在于尝试发现问题。如果哪位朋友也对这个问题觉得敏感，希望别人使用“>”来引用 Ta 的话，请留言说明，我们会尽可能地让你感觉舒服的。

现在各种标记语言都使用半格字符，写英文或代码为主的时候很方便，但是对于写中文为主的普通用户，就需要频繁切换输入法，这是个大问题！楼主能不能发明个适合中文输入法的标记语言？

@StarBrilliant

> 我也可以基于 Brainf*ck 语法来发明一个 Markup 语言，然后用来回复你的帖子，这样真的好吗？
-----[->+++++<]>-.[--->++++<]>+.---------.[++++>-<]>++++.[++>-----<]>+.[--->++++<]>+.--[->+++<]>-.---[->+++<]>.+++++.--[--->+<]>-.+++[->+++<]>+.---.-[--->+<]>-.[->+++<]>.[++>---------<]>.+[->+++<]>.+[->++++<]>.-[--->+<]>.-[++++>-<]>++.[++>-----<]>+.>++[++>-<]>-.[++++>-<]>++++.[++>-----<]>-.-[--->+++++<]>.[++++>-<]>+++.--[->++++<]>+.+[--->++<]>+.[--->+<]>.--[->++++<]>.>+[--->+<]>---.+[--->+<]>.>++[++>-<]>-.++.

我们设计的语法，认真读过帖子的说明是可以用头脑快速解析的；但 Brainf*ck 的语法即使了解 Brainf*ck 的工作机制，也不能很快用人脑解析。所以，不好。

有点意思。

如果属性里有“|”怎么表示呢？

比如： <div x="a|b"></div> 。

@oldj 用转义。这是这个语言里极少需要用到转义的地方。但由于属性通常比较短（相对于插入的代码段），所以实际使用应该不成问题。

例子：

(div x=|a\|b|)

名字帮楼主想好了，叫： LispML

嗯，我看完，能看懂（不能准确看懂），但是确实不能写……感觉学习成本太高了……类 HTML 学习成本都很高。

首先，你可以用 HTML 来写，有经验一点的人都能看得懂<del>，但是小白不一定了。</del>
如果我用 ** Markdown ** 来写，小白也能一眼看出来我强调的是哪里。 Markdown 的优点是看上去符合直觉。
说到底这是一个原则的问题，即解析优先还是阅读优先的问题。

@manfay

(quote .
现在各种标记语言都使用半格字符，写英文或代码为主的时候很方便，但是对于写中文为主的普通用户，就需要频繁切换输入法，这是个大问题！楼主能不能发明个适合中文输入法的标记语言？
)

谢谢。你的建议很有启发性，我们会考虑支持中文全角的特殊字符。我已经想好了如何支持这个特性，但现在还是倾向于不支持，因为将 ( 和 （等同起来意味着有时候要多敲两个“@”。请看：

半角模式：

(div .
拼（ pin1 ）音（ yin1 ）
)

半角加全角模式：

(@div .
拼（ pin1 ）音（ yin1 ）
@)

这是一个取舍问题，我们会再探讨。

初衷是什么呢.那个是软件开发之本啊.功能强大且全面的有 HTML,MARKDOWN 是为了全心书写而不顾及太多格式操作.
另外,MARKDOWN,先入为主,语法学习有成本,这个也是需要考虑的地方

按照楼主这样，我也能设计一种解释语言了，连解释器都写好了

#!/usr/bin/env perl

###解释器
sub F{
my $FMT = shift;
my $Text = shift;
if ($FMT eq 'i'){
return "<i>$Text</i>";
}
if ($FMT eq 'b'){
return "<b>$Text</b>";
}
return $Text;
}

###要被解释的语言
my $STR = <<"HEREDOC";
italic: ${(\F i,italic)}
strong: ${(\F b,bold)}
HEREDOC

print $STR;

================
运行结果
italic: <i>italic</i>
strong: <b>bold</b>

要不要玩玩这个？
http://www.nongnu.org/skribilo/

设计语言也要按照基本法

@geekyteen

(quote .
嗯，我看完，能看懂（不能准确看懂），但是确实不能写……感觉学习成本太高了……类 HTML 学习成本都很高。
)

我能理解你。其实，我们很多时候很容易把“不熟悉”等同于“难理解”，这是一个人类的认知陷阱。

新语法其实很简单（只有一条），而且规则。另外，属性其实是 optional 的，复杂度是可控的。

如果只要求达到 Markdown 的表达力的话，

(image src=|pic.jpg| width=|xxx| height=|xxx| title=|xxx| alt-text=|xxx|)

可以简写为：

(image src=|pic.jpg|)

@KylinRoc

(div class=|顽皮地一笑| .
：）
)

@zxgngl clojure 有套件叫 hiccup 似的

@Arthur2e5 很有启发，而且有的地方还很相似。谢谢～

私以为，主题帖里的方案太类似「程序语言」，用了太多的字符去描述并不十分重要的「格式」。最重要的是内容啊，格式应与内容脱离开来，不然不就成了上世纪的 HTML 了吗。

Markdown 的优点在于，它只用了很少量的符号去描述内容的类型，并且尽可能做到不干扰原始文本（源代码）的阅读。基于这个优点，不具备程序背景的人也可以轻松享受 Markdown 带来的便利（同时我也从不认为 Markdown 是程序员的私有玩具）。对于大多数情况，文本足够说清内容，各主流 Markdown 实现的插入图片功能用起来也毫无压力。

所以我觉得，楼主要么误解了 Markdown 的目的，要么选错了对手或方向。

@StarBrilliant 回想看到过的有限的邮件列表，貌似还真是这个样子，长见识了，特致感谢。

PS: 其实我觉得图片尺寸的控制也不该由 Markdown 来管，那样式的事情

@xuboying 我没有想着要“标新立异”，心中只有“简单实用”。关于一些“微创新”，请看一下 66 楼回复。

有实意字符的进入，必然导致阅读困难。对于专业文字工作者而非程序员来说，这个问题尤其明显。 Markdown 之所以能取得很多文字工作者的认同，显然是基于这种朴实的语法。这种标记语法接近于你在没有解析器情况下需要达到一些效果时所采取的写法，这是最大的优势。

@CupTools 不是的，我是想解决问题，顺便可能需要造轮子。

@StarBrilliant

> 这个世界上是先有“ Markdown ”，后有 HTML 的。
> 这个世界上是先有“ Markdown ”，后有 HTML 的。
> 这个世界上是先有“ Markdown ”，后有 HTML 的。

> 重要的事情说三遍。

不，可能是你搞错了， HTML 诞生于 1993 年， Markdown 诞生于 2004 年。先有 HTML ，再有 Markdown 。

https://en.wikipedia.org/wiki/HTML
https://en.wikipedia.org/wiki/Markdown

@StarBrilliant

> LZ 肯定不是 Python 用户

我用 Python 写过一套完整的高性能私有二进制协议的编码器和解码器。

@zxgngl 你没理解 @StarBrilliant 的意思，注意「 Markdown 」是加了引号的，他说的是类似 Markdown 的书写方式，而不是 Markdown 语言本身

@StarBrilliant

> UBB 的 [b]加粗[/b] 只能解释成 [b]加粗[/b]，不能解析成任何别的具有强调意义的形式。

“ b ”被解释成什么是解释器的事情，在解释器的层面是可以改变“ b ”的语义的， b 和*，－，### 一样只是符号。是解释器赋予了符号意义。

在我设计的语言中，标签的意义并不一定是写死的，我觉得可以通过配置文件进行扩展……

(ThisTagCanMeanAnythingYouWant . I mean, anything.)

@SilentDepth

> 你没理解 @StarBrilliant 的意思，注意「 Markdown 」是加了引号的，他说的是类似 Markdown 的书写方式，而不是 Markdown 语言本身

是的，你说得对，我理解错了，现在明白了。谢谢提醒；）

@zxgngl : 「在我设计的语言中，标签的意义并不一定是写死的，我觉得可以通过配置文件进行扩展」

这就容易出现「不结合解释器就无法看懂源文件」的问题。说白了，这是一个编程语言，已然超出了 Markdown 所在的领域。（让我想起了操作符重载）

@zxgngl : 「其实吧，我知道，自己设计个东西取悦自己，带自己带来便利就值了。自己工作中完全替代掉 Markdown 等各式，并因此变得更开心，也就基本上是极限了。至于推广啦、甚至广泛地代替 Markdown ，就几乎不可能了，至少我是悲观的。因为 Markdown 历史包袱太大了，好多基础设施如 GitHub 和 StackOverflow 都采用了它，这东西是很难变的。要说我是不是真的致力于推广新语法，让每个人都用上，其实不是的，也做不来。社区嘛，交流嘛、集思广益交朋友嘛～ 但我是真觉得这个新语法是比 Markdown 好的，所以才分享出来。虽然我知道由于一些认知偏见（中性词），比如把“陌生”等同于“复杂”，把“熟悉”等同于“好”，这个语法一开始会不招人喜欢。但是有什么办法呢？不折腾一下怎么好玩～」

这么说就让人伤心了。就事论事来说，主题帖里提出的方案相比 HTML/XML 没有明确而足够的优势，所以才会引来所谓的「偏见」。

自己设计个语言自娱自乐当然不是问题，只是既然发到 V2EX 上来了，我们（不要脸地代表一下其他人）不过是根据自己的见识提出些想法和建议。站在程序员的角度来讲，能提高做一件事的效率有何不可呢？至于推广什么的是后话了。

如果楼主要继续发展这个语言，个人完全赞成，万一走出了个全然不同的世界呢？:)

支持 po 主的动手能力，我还是先用 Typora 比较 High

@EugeneQiu 括号不是 Shift 键么？

@SilentDepth 别伤心，我做。