Markdown 编辑器横评(下篇)
本文最后更新于 128 天前,其中的信息可能已经有所发展或是发生改变。

我在 横评的上篇 中,对将近20款编辑器进行了一个初步的探索,然而这种“快速过一遍,凭主观印象”的方式不甚准确,故制定一些标准,来对它们进行一个更客观(但也免不了主观因素)的评价。

此部分横评覆盖了上篇中的所有Markdown编辑器——除了Microsoft Word这个来捣乱的。由于时间原因,测试项难免覆盖不完整,如果还有想了解的,可以在评论区留言,不过系统环境变化可能较大,不能保证结果完全可比较。

部分测试项在以下仓库开源:

TLDR

用一个Excel表格直观反映每项得分。没有考虑各项权重分配,并不能简单加和来得到最终结果。

基本信息

界面设计

首先映入眼帘的就是软件的界面,一个高颜值的界面能够带来愉悦感,而设计得当的交互能够提高使用的效率。当然这方面也和个人的感觉有很大的关系。

大部分编辑器都采用了较为简约的设计,以白色为主色调,在这方面Typora是当之无愧的标杆,主界面没有过于繁杂的元素,操作均收入顶栏,操作的分类安排也较为合理,能够很快找到想要的部分。但是也有很多编辑器简洁过了头,如Obsidian将很多常用操作都收进了右上角的菜单中,并没有很好的分类。WordMark将选项全都收进了按钮和Alt键菜单,这在macOS下可能无可厚非,但在Windows下十分别扭。VNote和Arya的编辑器界面有一定相似性,但VNote的界面看起来就更杂乱。Joplin的界面相对来说不算简洁,但很高效。

批判一番Zettlr,按钮布置十分杂乱,学习成本极高;配色奇怪而压抑,没有设计感。不过QOwnNotes才是重量级,乱得实在用不下去。

开源

软件开源,就意味着可以审查它的源代码来确保没有危险,对其作出自己的修改以符合自己的需求,或是为这个软件的开发完善贡献自己的力量。

闭源软件有Typora、Obsidian、马克飞象和WordMark,而VS Code和IntelliJ IDEA只有核心部分开源。

费用

大部分是免费的,收费的有整个收费和部分功能收费两种。目前整个收费的只有Typora,而StackEdit、IntelliJ、Obsidian和马克飞象有部分功能收费。StackEdit提供了Docker自托管的选项,同步云服务有一定困难,但导出PDF是免费功能。

Joplin是一朵奇葩,它的同步服务器也是开源并开放自建的。

值得注意的是,IntelliJ单作为一个Markdown编辑器的话,是免费的;而如果想获得基础Java支持之外的功能,则需要收费。

持续更新

持续更新的能力能在一定程度上代表适配系统新特性的能力。比如Linux下,新版本Electron才对Wayland有基本的支持,考虑到Markdown编辑器大量采用Electron,这个特点也很重要。当然,很久不更新不代表表现就会差,一直会更新也不代表表现会好。

Haroopad和WordMark的最后更新时间停在了数年前,而StackEdit和Notable也已经有一年没更新了。其余的在今年都有更新的记录。

跨平台与云同步

桌面端跨平台

这里的桌面端跨平台,涵盖的是Linux、Windows和macOS。有几款竟然神奇地支持了FreeBSD,但鉴于用户实在太少,不强求。

有Electron或者Qt加持的应用基本都能够正常支持跨平台,而网页端应用更不必说,凡是有浏览器的地方,就能跑起来。鉴于Windows版本一般没啥兼容性问题,笔者主要装了Linux版本试试。 Notable的Linux版本有时候跑不起来,而Wordmark的Linux版遇到了经典依赖问题——装不上(当时使用的是Ubuntu 22.04)。

另外还有一个异端Marker,仅支持Linux和FreeBSD。由于笔者没有Mac,此处也没有纳入许多Mac独占的优秀编辑器。

移动端跨平台

这部分网页端应用大获全胜,毕竟Electron又不支持移动端。除了网页端的几个应用之外,就只有VS Code、Joplin和Obsidian做了移动端支持。Obsidian和Joplin在移动端是原生应用,而VS Code用了另一种方案:直接把应用搬上了网页(vscode.dev,或GitHub Codespaces)。

这三款支持移动端的App一致性都做得很好。

云存储接入

少数编辑器有自己的云存储空间,并作为增值服务售卖,如Obsidian;其他的编辑器(如StackEdit)则会依赖第三方的云存储,如OneDrive和Google Drive等。

LetsMarkdown似乎使用了一种不同的方案。出于协作需求,它会将用户的文档默认保存至服务器。

WordMark和StackEdit面向的是blogger,也就接入了WordPress、Medium和GitHub平台发表文章,就算它是个同步吧。

Obsidian、VS Code和IntelliJ还提供了Git插件,但鉴于不是自带Git客户端,此处不算作接入云存储。

QOwnNotes接入了Nextcloud和ownCloud等云存储服务,对自托管的服务支持较好。

Joplin支持官方云、自建同步服务、OneDrive等同步服务。

编辑体验

指示功能

在主界面上常驻一些字数统计之类的功能是有必要的,而太多了则会适得其反。

测试中,WordMark的字数统计完全无法正常使用,其目录也因为无法正确识别标题而难以使用。

有目录的有Typora、Obsidian、MarkText、Notable、Typedown。

有字数统计的有VS Code、Typora、Obsidian、StackEdit、MarkText、Zettlr、Haroopad、QOwnNotes、Typedown。

图片管理

Markdown是纯文本格式,无法内嵌图片,所以需要额外的图片解决方案。有的会将图片存放在某个目录下,而有的支持上传至第三方云平台。

存放于工作区内的有Obsidian、Typora、MarkText、Zettlr、IntelliJ、VNote、Notable、QOwnNotes、Joplin,一般都是粘贴时自动保存到工作区的特定文件夹中。

能够上传到云端平台的有WordMark、Typora、MarkText。

剩余的仅能插入外链。

导出体验

一般来说都是导出PDF,所以此处重点体验PDF导出的质量,对其他格式只作数量要求,反正一般也是Pandoc实现。

Notable和Marker不知道咋回事导不出,就算了。

PDF可自定义度

一些软件可以自定义PDF导出的格式,从单纯的页面设置、页面主题,到可自定义CSS。

支持多种内置主题的有StackEdit、MarkText、Typora,其中Typora一个非常强大的功能是可以使用CSS完全自定义主题。

支持设置一些页面参数的有Obsidian和MarkText。

PDF渲染质量

对于这一项,一般来说渲染没问题的都会得10分。值得注意的是,一些软件导出的PDF与预览有所不同,比如Zettlr导出后能够支持预览并不支持的规范。

Obsidian对数学公式的渲染匪夷所思,虽然支持TeX公式,但渲染出来字体竟然是黑体。

Dilinger虽有导出功能,但大量字符缺失,中文字符更完全无法显示。

VS Code和IntelliJ在无插件的情况下不支持导出。

QOwnNotes的情况有点奇怪,它会将Markdown符号一起导出,而非纯净的预览。这方面见仁见智,不过我给扣了分。

还有的PDF导出后竟然比软件内预览的兼容性更强……很怪。

其他格式数量

其实没啥好说的,能调用Pandoc的就有优势呗。

CommonMark 语法

CommonMark标准是对原版Markdown规定的细化,内含基础的Markdown语法,更适合作为一个基本的Markdown要求。

此部分的得分是能正常通过的测试项数量。通过数量多的一定代表好,但通过数量少的也不一定难用,因为其中也包含一些平常不会触及的corner case,而CommonMark也只是其中一个标准,并无强制性。

基本

此部分包含“字符与行”、“制表符”、“转义字符”、“实体和数字字符”这些方面。

WordMark最惨,即使是Electron,稍复杂的格式基本无法正常渲染。

叶块

此部分包含”ATX标题”、“设置文本标题”、“缩进代码块”、“围栏代码块”、“HTML块”、“链接引用”、“段落”等方面。

这里大部分编辑器没有得分的地方是paragraph部分。CommonMark要求两行之间间隔一行才能算作换行,而大部分编辑器并没有严格遵守,渲染出了5行(本应该是2行)。大部分情况下其实也可以不算一个问题。

“设置文本标题”部分出的问题也千奇百怪,有的只能识别一行标题,有的甚至识别不出标题。

Joplin避过了所有的坑,成为惟一一个全部通过的编辑器。

容器块

此部分包含“块引用”、“列表项”两个方面。

有的编辑器如马克飞象和Marker等,会直接将自定义序号替换成从1开始编号。

内联

此部分包含“代码块”、“强调和特别强调”、“链接”、“自动链接”和“图片”几个方面。“代码块”部分特增加了几个非传统热门语言。

此处着重说一下代码块。C的高亮应该是只要支持语法高亮就会包含的,而新兴的如Rust,以及没那么热门的Verilog/汇编则支持较少。Typora是唯一一个能支持汇编(assembly)渲染的编辑器,而大部分出现0.5分的编辑器都是因为语法高亮支持不全。

GFM 语法

GitHub也是使用Markdown语法较多的平台,它在一定程度上扩展了原版Markdown的语法,形成了GitHub Flavored Markdown标准,也有一定的影响力。

表格

绝大部分编辑器都不能正常渲染\|的转义符号,虽然不会将其识别为表格分隔符,但显示仍然是\|而不是期望的|

待办列表

Marker成为了参测编辑器中唯一一个不支持待办语法的编辑器。

自动标题

GFM的自动标题相比于CommonMark添加了对没有任何外加标记的链接的直接识别。很少有编辑器能够将邮箱地址自动识别为mailto链接,大部分都较为保守,毕竟也有一定的误识别可能性。

图表

GFM定义了Mermaid、Geojson、Topjson和STL模型四种图表格式。都是基于代码块定义的。尴尬的是,哪怕表现最好的编辑器也只支持Mermaid,而后三种只有GitHub网页能正常显示。

后续可能会增加PlantUML等其他图表的测试?等有空再说吧。

数学公式

GFM定义了使用两个$符号的公式块、使用一个$符号的内联公式,以及使用代码块格式的公式定义。此外还借用了 这篇文章 中GitHub数学公式的一些bug。

性能

渲染较大规模文档的能力也是很重要的一个方面。这里使用从Project Gutenberg下载的《战争与和平》英文版(56.5万词,3MB),并转换为Markdown文件用于测试。对于能在Linux安装的编辑器,测试环境是Ubuntu 22.10开发分支,AMD Ryzen 7 4800H,24G内存,GeForce GTX 1650+NVIDIA闭源驱动。如果不能安装,使用Windows 11 22621.160。对于网页版编辑器,这里忽略平台不同的影响,均选择Firefox最新版本,使用浏览器任务管理器查看内存占用。

StackEdit最大支持打开约250KB的文档,剩余部分被截断,无法完成测试。Typora不支持打开此大小的文件。Zettlr查看时经常卡死无响应。Arya粘贴后直接卡死。Marker完全无响应。

打开时间

打开软件,从软件中的打开方式打开文档开始计时,到加载出正确渲染的文档内容。

VS Code的代码加载很快,几乎马上就能加载出来,但预览很慢。类似的情况也在类Typora的所见即所得的编辑器中出现,如果需要将整个文档渲染一遍,就会花很长时间。

内存占用

需要注意,网页端和原生应用的内存占用不能直接比较。网页本身的内存占用通常很小,许多浏览器本身动辄占用几百兆内存,而大部分Electron应用相当于再开了一个浏览器。

流畅度

将流畅度从0-10打分,很流畅则得10分,完全无法正常浏览则得0分。

v2ex网友说MarkText有性能问题似乎是真的,不过能打开也比Typora强了。

VS Code不知道吃了什么微软神油,编辑和浏览都巨流畅。

另记

Typora的数学公式渲染需要手动开启。

VS Code缺失的部分基本可以使用插件开启,如导出文档、Mermaid图表等。

哦忘了说了,Electron就是个垃圾。

评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇