@popbones

> 不太适合人类阅读，容易出现行为一大串)和修饰字符和正文自负不好分辨的情况。

可以举个具体的行尾出现一大串 ) 的例子吗？

> 可以作为 XML 的某种模板或为了节省空间的存储格式（节省有限）因为表达集基本差不多，但是和 Markdown 比没什么优势， Markdown 的一个重要优势是即时当作纯文本来读对人类来说大部分时候也很容易。

请举个具体的 Markdown 很好读但我设计的格式不好读的例子吧。

> 如果作为编译成输出文档的源码，不太关心可读性但是比较在意表达能力的话竞争太多，比如 LaTex

在功能上，由于我的格式语言只是处在设计阶段，所以跟 LaTex 比功能（如输出 PDF 、 PS ，画数学公式）是望尘莫及的。但在语言设计上 LaTex 等语言有一个致命的问题就是当用 LaTex 写 LaTex 的说明文档的时候会由于转义字符的原因导致非常难写。具体例子：

LaTex 有以下十个特殊字符：

& % $ # _ { } ~ ^ \

如果要在 LaTex 文档中表示它们需要这样写：

\documentclass{article}
\begin{document}
\& \% \$ \# \_ \{ \} \textasciitilde \textasciicircum \textbackslash
\end{document}

我设计的语法包含以下六个特殊字符：

( ) @ = | .

在新语法中表达它们是这样的：

(@article .
(@document .
( ) @ = | .
@)
@)

哪一种语法更清晰简洁比一下立刻就见分晓。

@master13

> 所以这种语言跟 HTML5 的区别在哪里？

在 HTML 里面如果想表示 “<你好>” 需要输入转义后的 “&lt;你好&gt;”，使用我设计的语法对于任何字符或字符串都不需要转义，方便拷贝和修改。第二个好处是可以支持第三方格式，如 CSV 表格。第三个好处是写的少，语法一致性高（只有一条语法）。

@codefalling 这个语法一开始的定位之一就是博客的“源代码”：）

@jemyzhang

> 看上去楼主并不理解 md 的精华所在，那就是可读性

窃以为， Markdown 就是一些约定俗成的 hack 拼凑，没有什么原则可言，也没有什么精华的。

@cevincheung 看不懂。请说中文。

@10iii 你这种表达方式是可能伤到人的，而且帮不到人。请看我的原帖、我的回复以及回复中对语法的补充说明。

@LioMore

> 刚看了其他人的回复，现在觉得楼主的语言和 HTML 的关系越来越像易语言和 VB 的关系了

我想，你想说的是我的语法和 HTML 差不多。但我的语法是可以解决诸如易读性差，入代码可能需要转义等直接使用 HTML 会遇到的问题。

另外，请不要光看其他人的回复。请看我的原帖、我的回复以及补充说明。

@CJey

> 在这里，我看不到简洁，除了复杂和弱表现力，剩下的就是可能解决了让你不爽的 quota 方式， so ，没意义，因为 quota 无法避免，更不要试图更改大家的习惯，这会让人排斥

我假设你说的“ quota ”指的是“引用文字或代码”（ quote ？）。我设计的语法一劳永逸地消灭了插入文字和代码时可能会需要对插入对象中的某些字符进行转义的问题。

是否简洁是主观的，就不说了。

你用了“弱表现力”这个词来形容我设计的格式。我想知道，有什么你觉得这个新语法表现不了么？

@woai110120130 现在没有程序，只有设计。

@nekocode 我觉得我设计的格式才是专注内容，任何人都可以很容易书写，而且“可以方便地书写任何内容”的格式。

@dcoder Emmet （ http://emmet.io/ ）通过语法的扩充和编辑器的辅助功能，使写 HTML 变得容易快速了，但并没有解决读 HTML 以及在 HTML 中插入代码可能需要转义的问题。

@zhulaole 可以发邮件联系我。地址请见签名。

@laosb

我的（不全面且主观臆断的）观察是，多数情况下人们通过纯文本模式或者编辑器的 Markdown 辅助模式来“写”文档；但“读”的时候，多数情况都是渲染过的样子，而不是原始的 Markdown 文本，这也是为什么 Markdown 编辑器这种按照 Markdown 设计初衷本来不应该存在的东西广为流传甚至还能卖钱的原因。

“ quote ”的意思是“引文”，语义类似于 HTML 里面的 blockquote 标签。这个帖子发表在“程序员”节点下，所以我假设大家是懂的。没有让大家清楚明白地知道这个单词的意思是我的错，抱歉各位。

@SilentDepth 别伤心，我做。

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

@SilentDepth

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

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

@StarBrilliant

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

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

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

(ThisTagCanMeanAnythingYouWant . I mean, anything.)

@StarBrilliant

> LZ 肯定不是 Python 用户

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

@laosb

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

其实，我设计的语法是可以兼容 Markdown 的朴实语法的。对于文字工作者来说，如果能够接受：

### H3
*asterisks*
_underscores_
~~Scratch this.~~
[I'm an inline-style link]( https://www.google.com)
和
table | in | markdown
--- | --- | ---
a | b | c
1 | 2 | 3

那么应该也能够接受（如果不是更容易）：

(### . H3)
(* . asterisks)
(_ . underscores)
(~~ . Scratch this.)
(span link=|https://www.google.com| . I'm an inline-style link)
和
(table plugin=|csv-paser| .
csv, based, table
a, b, c
1, 2, 3
)