去年 6 月的时候,我在这里说准备设计一种轻量级标记语言,当时反响一般,我想主要原因是那时我自己都还没有把要做的事情完全想明白。一晃一年多时间都过去了,终于写出这个标记语言的初稿,并将它叫做 InkMark。
相对于其他各种轻量级标记语言,InkMark 具有以下特性:
**着重强调**
表示要 着重强调 的文本,Inkmark 中却使用 *[着重强调]
达到同样的效果。InkMark 不像 Markdown 几乎为每种常用元素定义了简单且直观的标记方法,它很“死板”,几乎是为所有元素定义了相同的标记规则。因此 InkMark 不如 Markdown 那么直观,也不如 Markdown 那样特别适合编写程序开发文档。但 InkMark 的标记规则相对更容易学习,并且其表达能力要强得多。其元素内容的边界范围也更加明确,不容易产生歧义。当只使用常用的标记功能时,它几乎和 Markdown 一样简单。
和 HTML 相比,InkMark 的完整模式几乎具有和 HTML 相匹配的描述能力,但元素边界不如 HTML 那样通过起始和结束标签项明晰标示。而 InkMark 的简写模式则要比 HTML 简单得多,适合手工书写,且源代码也更易读。InkMark 能做到在完整模式和简单模式间无缝切换,很好地在简单和功能强大间取得了平衡;不过两者进行切换的规则需要额外的学习成本。另外,针对学术文档的书写这一特殊目的,InkMark 通过加入一些自定义元素大大增强了其表达能力。
相对于 LaTeX 这种专业的学术论文排版系统,InkMark 主要专注于为文本添加常用的结构和语义,而其他更多的功能,如文本和页面样式,则大多交给其他程序(如和网页关联的层叠样式表 CSS )来完成。因此,其功能要远远少于 LaTeX,但也简单得多。
目前我只是用 HTML 格式写了一个长长的文档,真的是很长很长的一个文档,干这个事的难度比我预想的大多了。暂时先把这个文档发布在我的博客上:
这么长的文档,里面肯定有表述错误,请大家不吝指出!
我自己没有精力编写该语言的解析器,我只是先把这个文档放出来,看看大家的反馈。如果反响不错,将会进一步投入精力,并希望能有更多的人参与这项工作。
期待大家的讨论,谢谢!
我自己也拿不准:我究竟是设计了一个怪胎,还是一个简单强大的标记语言。
因为我自己对这些规则很熟悉,用 InkMark 替代 Markdown 写学术类的内容,真的是舒服太多了。但对于其他人,要掌握起来恐怕还是不容易。
因此,如果将来写 InkMark 的帮助文档,肯定不能像我现在设计 InkMark 写的文档这样,而是应该从简单到复杂逐渐讲起。比如,分 5 级,当别人学会以后,分别告诉对方你入门了、小成了、变成熟练工了、成为大师了、无敌至尊了——举个庸俗的例子而已。
以下是一些示例:
段落就是直接写,用空行分割的文字。
换行直接用回车就行了:
远远的街灯明了,
好像闪着无数的明星。
天上的明星现了,
好像点着无数的街灯。
标题用 = 标记而不是 #:
= 一级标题
== 二级标题
行内元素标记:*[着重强调]、/[强调]、-[删除]、+[插入]、`[代码]、?[注释]、^[上标]、_[下标]。
链接:@[V2EX][https://www.v2ex.com/]
* 无序列表项 1
* 无序列表项 2
/ 无序列表项 2 中的第二个段落
* 无序列表项 3
** 无序列表项 3-1
** 无序列表项 3-2
代码:
` [
package main
import "fmt"
func main() {
fmt.Printf("Hello, 世界!\n")
}
] [Go]
自动编号的参考文献:
#[张三, 李四, 王老五, 等. 示例文章标题 [J]. 示例期刊名称, 2021, 33(8): 335-341.][reference][number="[{{#}}]"][template="^[ {{#}} ]"]
以上文献将显示为 [2] 的形式。
引用以上自动编号:#[label="编号标签"][ref="reference"][template="{{#}}"]
内部具有一个图像、一个图像标题、一段图像描述文字的图像框:
& [src="https://inkmark.org/path/to/picture.png"][caption="图像标题"][alt="替换文字"][description="用一个段落对图像信息进行描述。"]
最简单形式的带标题带编号的表格:
++ [
-! 第 1 行第 1 列 ! 第 1 行第 2 列 ! 第 1 行第 3 列
-! 第 2 行第 1 列 | 第 2 行第 2 列 | 第 2 行第 3 列
-! 第 3 行第 1 列 | 第 3 行第 2 列 | 第 3 行第 3 列
][表格标题][label="table"][number="表 {{=}}.{{#}}"]
我又写了个 InkMark 简介,这次是从简单到复杂逐步进阶介绍的:
1
renmu123 2021-08-25 16:30:47 +08:00 via Android
我觉得你是什么都想要,既想要 md 的简洁,也想要 html 的表达力,也想要 latex 的排版。贪多嚼不烂啊,很难把握好这三者之间的度,你要考虑好可能得受众群体
|
2
humpy 2021-08-25 16:37:58 +08:00
既然方括号在你的语言里这么重要,不如叫 BracketMark 😜
|
3
chingli OP |
4
oott123 2021-08-25 17:35:45 +08:00 via Android
是有点怪。我个人感觉这玩意更适合当某种模板引擎,去和 pug 竞争,而非文档领域。另外我觉得你应该直接贴一些示例出来,翻了半天才看到示例。
|
5
stimw 2021-08-25 17:44:19 +08:00 via Android
我觉得写英语文档在英语社区推广,比在中文社区推广容易得多。
|
7
chingli OP |
8
Kilerd 2021-08-25 18:36:25 +08:00
太复杂了。 简单的用 md,复杂的我肯定就直接上 latex 了
|
9
eason1874 2021-08-25 18:44:56 +08:00 2
乖乖,跳过前言直接看示例,看了几分钟才发现滚动条还在上面,全部得有五六万字,认真看完都得一小时了吧。
轻量级应用是不需要说明设计思想的,只需要使用说明和示例。轻不轻,用户能直观感受到。 Markup 重语义,Markdown 重阅读,你是什么都重。看样子是思考了很多,但是还没有确定侧重点,做不了取舍,于是做出来一个大杂烩。 你要是想做偏学术类的轻量级标记语言,建议直接继承 Markdown 通用语法,把设计重点放在学术表达的部分。 |
10
namelosw 2021-08-25 18:50:00 +08:00
我感觉 Markdown 作为轻量标记其实已经很不错了,唯一的明显缺点就是标准混乱且解析有歧义
如果不考虑轻量标记的话,Markdown 最大的问题是很多元素不能很好地自我嵌套。 不过一旦有自我嵌套就会啰嗦一些,不然是括号眼晕打着麻烦,不然是缩进容易写错。 |
11
Tink 2021-08-25 18:51:56 +08:00 via Android
主要是得有人用
|
12
chingli OP @Kilerd LaTeX 比这个复杂多了,我认为有点不适合现代的面向 Web 的写作。
@eason1874 这个也没有太复杂,主要是我确实是从设计思想的角度写了比较多,没有从初学者的角度写。 学术写作还是比较复杂的,面对复杂的问题,也往往只能有复杂的解决方案。 可以看看 CommonMark 的规范,如果用 Chrome 的打印功能,A4 纸默认样式下也要 114 页了,我这个才写了 71 页。 @namelosw 真要写复杂的学术内容,Markdown 还是差很远,并且好多都是系统性的问题,改不动啊。 V2EX 的用户大部分都是搞编程开发的,对复杂的学术文档的写作需求的理解并不是很清晰。看来我的确需要从初学者的角度再写一个文档,这样才能让大家明白我究竟想怎么做。 |
13
namelosw 2021-08-25 21:00:24 +08:00
@chingli 我能理解你的这个定位。LaTeX 重得有点没必要,Markdown 有时候不太够用。
Markup 主要分两种,一种是偏读写的,一种是偏结构的。 Markdown 的问题: 1. 偏读写:缺少结构,我看你主要靠 [] 嵌套解决这个问题。 2. 不太够用:应该提高扩展性而非功能,我看你有类似 directive 一样的东西来增加扩展性。 不过有个问题是全靠 <></> 或者 [] () 之类的的元素,就会写起来比较不爽。如果觉得不会不爽的话,其实 LISP 就已经是最好的 Markup 了。如果像 Markdown 一样不靠 [] () 嵌套,一方面表现力下降,另外一方面需要减少符号,比如 & 很常用,如果作为特殊符号就要经常转义。个人感觉缩进可能是一个比较好的折中方案,只是不知道非程序员是不是很容易把缩进搞混(虽然很多人抱怨缩进,但是我就没见过 Python 程序员日常会把缩进搞混的)。 我看你好像不是 IT 人员,可以推荐几个值得参考的 markup ( just in case 你没看到这几个竞品): 1. Jade:一个模板语言,更像 HTML,用的缩进形式。https://jade-lang.com/ 2. reStructuredText:Python 社区很常用,主观感受流行度可能仅次于 Markdown 。https://docutils.sourceforge.io/rst.html 3. Org Mode:Emacs 内置的 markup,用户很多,扩展也很多,除了当 markup 之外更多做 GTD,日程管理,有时候还会当简单的 Excel 用等等。GitHub 除了支持 Markdown 之外其实也支持 Org 。https://orgmode.org/ 4. Scribble:Racket 社区的通用 markup,本质上是 Racket 的一个库 /语言,因为是 LISP 所以扩展性很强。https://docs.racket-lang.org/scribble/ 5. MDX:这个不太算 markup,本质上是一个 Markdown + JSX 预处理器,但是这样其实就相当于 Markdown + React,那么威力一下就提高了。不过 Markdown 和 JSX 之间其实结合的并不好,很多时候从 JSX 里面套回 Markdown 虽然可行但很别扭(不过这个是 Markdown 的问题,用了 HTML 里面就不能再用 Markdown 了)。https://mdxjs.com/ |
14
AX5N 2021-08-26 02:37:15 +08:00
感觉设计得挺烂的,而且连解析器都没有,你是不是从来就没用过?如果你自己都没用过,那你怎么知道你设计的东西哪里有问题,哪里可以妥协,哪里不能妥协?你先拿你这个 mark 去把各种类型的文档都写几遍,凑个万把字再说吧。
(我用我自己设计的标记语言写过几十万字(2Mb)的内容) |
15
GiantHard 2021-08-26 08:38:25 +08:00 via Android
感觉你这个 markup 的定位有点类似 asciidoctor
|
16
chingli OP @namelosw 你都说到点子上了。我设计的这个东西的确解决了你所说的 Markdown 的两个问题,但太多的方括号使其看起来有点丑陋。
我现在只是部分解决了方括号过多导致丑陋的问题,就是规定若块级元素只占一行时,可以不写方括号。另外,当列表项元素包含多个段落时,也可以通过使用斜线表示的接力棒 / 标记而不使用方括号。 虽然用方括号很丑陋,但是针对我想解决的问题,我找不出更好的方法。比如,学术文档中往往一个表格单元格内还包括多个段落,我找不出除了用括号外能更好地包括这多个段落的方法。另外,我也找不出不使用括号而给元素添加属性的好方法——为元素添加属性在实现复杂的功能时真的很有用。用括号还有一个好处,就是元素内容的边界清晰,学术内容可能包含各种标点符号,像常规的用 *强调* 形式的标记方法,很可能和内容中的乘号相混淆。 Markdown 中的缩进规则是比较复杂的,我觉得除了程序开发人员,其他人员对多少个空格根本不敏感。我常常给学生们改 Word 论文,其中存在太多的胡乱用空格的情况。甚至好多时候,文档中多出一些空格他们都会视而不见。因此,我从最初的设计时,就排除了利用行首和行尾水平空白作为标记的方式,即完全忽略标记内容开始和结尾的空白。 我也看了许多已有的标记语言(但没有全部看完),都不如 Markdown 那样简单明了。大多数标记语言大都针对每个元素类型设计了独特的标记规则,标记方法太多,不好记忆,在 InkMark 中也不够用。我这里力求规则一致。但这个文档看起来仍然复杂,主要是因为自动编号元素有点复杂了(其中的 number 和 template 属性看起来有点像模板语言),以及对属性的支持使得格式有点凌乱。 另外,我在设计时,也并不是一直想着要简单。因为复杂的问题往往必然只能有复杂的解决方法。看看 MediaWiki 的标记语法,虽然基本语法比较简单,但完全不够用,必须配合使用 HTML 以及模板,大多数维基页面都充斥着这些复杂的混合标记。所以我不如一开始就把一些功能设计得稍微复杂一点,可扩展性强一点。当然,我现暂时在还不敢往里面加模板功能,那样就太复杂了。 对于非编程开发人员,我现在第一担心的是他们能不能分清行内元素和块级元素,而我设计的这个标记语法在进行标记时,必须首先能区分这两类元素。 |
17
chingli OP @AX5N 请不吝指出问题。
这么复杂的一个东西,我若不是思考及实践很久,是弄不出来的。我现在是把整个思考过程都清晰地写出来了,这并不容易。我自己也用这个语言记笔记,期间对其设计语法作出了很多改进。但只要持续思考,就必然仍有很多改进的空间。我的确没有写出其解析器,我没有精力,并且也不是应该首先做的事情。 您既然设计过同类的语言,肯定很容易看出这个东西的缺点。我把这个东西放这里就是找别人批评的,很期待你的详细点评,不过还是应该以和我同样的设计出发点,即写作复杂的学术文档的角度来进行评价。 |
18
tysb777 2021-08-26 10:01:55 +08:00
支持一下
|
19
2i2Re2PLMaDnghL 2021-08-26 15:23:26 +08:00
这是不是不能在代码块中写那些方括号不对称的语言?
或者说,能不能写这一段代码? `[ s.find("]") ][Python] 写学术类的内容,pfm 挺好的 |
20
chingli OP |
21
2i2Re2PLMaDnghL 2021-08-26 15:57:52 +08:00
@chingli pandoc-flavored markdown
我记得哪个 markdown 分支是可以 ``s.find("`")`` 来绕过的,可以无限叠加,只会匹配相同数量的。 而对于里面恰好是一个 js template 那种,也可以 `` `12+34=${12+34}` `` 这样前后各加 1 个空格,会抹掉这两个空格。 |
22
chingli OP @2i2Re2PLMaDnghL 我原来也是想着在 InkMark 中可选性地允许多层方括号,但要求左右两侧的方括号数目必须相等,这样可以规避该问题。例如:
` [[ s.find("]") ]][Python] 后来觉得规则太多,就没有用。现在其实还是应该考虑一下这个规则。 |
23
henryhu 2021-08-26 16:18:27 +08:00
tldr
|
24
zjm947373 2021-08-26 17:29:52 +08:00
😃一般这种事情被大多数人不看好的地方,其实不是一个东西的设计是否优秀,而是很多人只停留在设计上面,匆匆地宣布自己设计了什么,应该反过来先基于这种标记语言做一个非常好用的、优秀的编辑器 /记事本软件等,再回头来吹自己所设计的语言不迟
|
26
leokino 2021-08-27 04:06:17 +08:00
如果没有形成 Specification,没有写 reference parser,这个工作其实还非常早期。
|
27
leokino 2021-08-27 04:13:35 +08:00
作者对于[][]部分元素渲染的构思以及表格的展示还是很有创意的,但是其他部分略显多余,包括对其他 @链接元素的定义。这个标准独立存在的可能性不大,作者可以将上述两部分抽离出来,作为 Markdown 的插件实现,前景会更好一点。
|
28
chingli OP @leokino 作者对于[][]部分元素渲染的构思以及表格的展示还是很有创意的。乱码了,不知道你写的“[][]”是什么。
|
30
yakun4566 2021-08-27 15:05:14 +08:00
别发了,学不动了 /:doge
|
31
althoughghgh 2021-08-27 18:24:20 +08:00
和 asciidoc 很像,它可以自定义扩展,加入自己的符号,输出的 html 也是可定制,模块化的
给主流语言写 parser 很困难把,另外还得弄个编辑器,不然也没人用 |
32
chingli OP 我准备再如下几方面改进:
1. 原来设定完全不用行首的水平空白作为标记,现在放弃这样做。许多时候,行首空白还是很有用的,适当利用行首空白进行标记能使文档更加美观。 2. 进一步多参考 Markdown 以及其他标记语言的优点,让显示效果更漂亮一点。 3. 想办法简化自动编号、图、表、公式、参考文献的表达,但还是想办法保留对编号的各种设置,毕竟这个东西真的很有用。 4. 设法使文档书写过程中基本可以不用转义。 5. 改个名字! 不过,还是要保留目前这种方括号对接龙的标记语法(只是对部分块级元素,可以通过简化而不写方括号),以及对额外的元素类型、属性的支持,从而使其具有与 HTML 相匹配的表达能力。毕竟,如果不这样,就没有存在的必要了。 谢谢各位! |
33
sccbhxc 2021-09-06 13:40:20 +08:00
楼主加油
|