changed 3 years ago  
Linked with GitHub

为数学家设计的知识管理系统

个人使用

常见的数学家自用的知识管理系统

数学人在计算机上做笔记要弄一整个\(\LaTeX\)文件。用自己的文本编辑器修改。编译成PDF。出现一堆看不懂的编译ERROR，手动修改。编译时间也要几秒。这个系统原本是为了生成可以打印出来的论文的，因为\(\TeX\)本质是一个排版软件。对于论文来说，输出的目的就是一个完美的排版好的论文。

但如果目的只是为了记录点笔记，或者管理自己研究中发现的东西，实际上根本用不到排版的功能。甚至就算是发论文，真的排版的使用也极少。

以下是写数学笔记的人常要用到的功能。

  1. 标题等基本的结构信息系统: 大多比如heading一样的东西。还有重要的就是Theorem environment。例子 
    ​​​那我们引入下面的定理
​​​\begin{theorem}[代数基本定理]\label{thm:algebra}
​​​    啊这个定理该说的东西blahblah
​​​\end{theorem}

    那我们引入下面的定理

    定理1.1 （代数基本定理）
    啊这个定理该说的东西blahblah

  2. 数学公式: 例子: $x^2$

    \(x^2\)

  3. 内部引用: 例子: \cref{section:introduction}提到的\cref{theorem:algebra}显示

    Section 1.1提到的定理1.1显示，

  4. 外部引用: 需要可以使用bibtex。文件里引用bibtex的信息。例子: 可以看Bakh的论文\cite{bakh98, bakh99}

    可以看Bakh的论文[3,4]

这个系统用来记录笔记或者写论文，都有很大的缺陷。

  1. 写作速度过慢：写源码，编译，查看。对于很大的文件，能达到十几秒的等待时间。
  2. 修改的loop也很慢。自己输出的PDF上看到了问题，要去TEX源文件里找具体在哪里，做出改动，查看。一个小错误都可能要30秒才能fix。常见做法是打印了draft。发现问题圈起来，找到大多问题之后跑到tex文件上做batch的修改。费时费力。就是有PDF的inverse serach，还是有一些摩擦。
  3. LaTeX Debug也非常复杂：有时丢了一个$就能找很久。
  4. 生成的是PDF在网络时代并不好分享：PDF还是适合打印。
  5. 不支持多个不同的文件的简单内部引用：可以弄一大堆tex/生成的pdf文件。自己建立文件夹管理这些文件。但还是很麻烦的。

所以想要一个新的记录笔记的系统。这个系统应该是在浏览器里，输出HTML，便于分享，也便于交互。

一个写数学文章的人的一些观察

在写文章中我会觉得人存在于两个模式之中。写作和编辑。读者会在阅览模式。

这几个模式下，人的行为是不一样的。

写作模式：

几乎所有的时间是在写东西。目标是快速的将自己脑子里的东西变成（接近）自己想要的输出。

这个时候，大多时间需要输入部分无摩擦。可以看任何一个数学人用的\(\LaTeX\)文档。用数学公式的次数远远大于任何其他功能。什么加粗，列表，等等，在能快速插入数学公式之前都没啥意义。\(\LaTeX\)实际上用\( \)来控制公式，只有\(\TeX\)才是用$ $. 但是$是主流的最大原因就是输入数学公式的时候需要尽量减少摩擦.

而写作的时候的确可以不需要live preview。人会输入很多东西，才要知道具体输出是什么。感觉一整段话写的差不多了，才会想看看输出结果是什么。

编辑模式：

文章几乎已经完全写好了，要开始对文章做一些修改。这个时候，人主要是看输出的结果。在输出的结果里看到了问题，希望可以直接修改。

用现有的系统，这是非常痛苦的。我\(\LaTeX\)写好了东西，改文章的时候一般是打印出pdf，仔细的看。找到了所有有问题的地方，再回到代码那里一次性的做改动。很快会发现每一个改动平均可能要花20秒的时间来找到它在源代码的哪个地方（inverse search很重要）。如果有所以60处小改动，20分钟就花在了纯粹的locating上。

如果可以直接在输出上做改动，则好很多。

阅览模式：

人只是想好好的读文章，对修改没有什么要求。这种情况应该有一些让读文章舒服的工具。也就是尽量保证人阅读的flow。

比如读文章的时候常常会有reference一个其他东西。如引用一个定理、citation等东西的时候，我希望很快的知道那个定理究竟是什么，而不是翻页翻到了那里看一下，再回来。有个pdf浏览器有那种quick preview的功能，可以到了某个链接迅速的显示出那东西究竟是什么，甚至包括少许上下文。

一些想法

  • Markdown是最合理的写作方式吗？应该根据人本身的写作方式创建一个最适合自己的输入形式。比如，不怎么写代码的人，markdown里用indent创建的代码block的意义是什么呢？
  • 编辑模式中，发现了问题可以快速的修改。也就是能在输出的地方找到错误，可以把自己送到对应的输入的地方。

所以应该有个存在3个不同的部分的系统，并且可以互相对应。也就是以下3个层之间的变换。

  • 输入层，这个是自己的输入language。可以想象是markdown。但是什么都可以。输入层的目的应该让写作和编辑没有摩擦。
  • 逻辑层，这个是我们应该定义出来的一个AST。可以表示我们想要的所有语义。
  • 输出层，根据逻辑层AST render出来的输出。输出层应该让编辑和阅览没有摩擦

研究过Pandoc的人会发现这不就是pandoc: Reader, Pandoc AST, Writer。就是要多加点信息，可以保证从输出层对应到输入层。

这边要提到Typora那样。输入和输出部分几乎是放在一起的。也就是除了光标所在的地方，都是输出的样式。Typora的granularity过细。以前的版本改比较大数学公式的时候各种跳来跳去痛苦极了，不知道现在如何。改为每一行的granularity可能不错。也就是光标所在的行，只显示输入层，光标不在的行都是输出层。或者让用户可以自己选择。

要满足这样的系统，上面三层应该满足某些局部对应和局部转换的功能。好像有个叫Bidirectional Transform的东西可以研究研究。

现在的替代品

Markdown Editors和知识管理系统

市面上有一些可以用做笔记的工具，大多数用markdown。我测试过这些系统: Quiver, Roam Research, Obsidian, Coauthor, Dropbox Paper, Notion, Typora, 我自己博客(Hakyll + Pandoc + 自己的一些脚本), tiki wiki, MediaWiki, Dokuwiki, 飞书，Zettlr, Logseq。但上面这几点全能做到少之又少。数学家喜欢的功能非常小众，他们的需求有时其他人用不上。很多工具决定了一定要支持的是Markdown，整体是为了markdown用户考虑的。

以下功能很少一个软件完全支持。

  • 支持定理、证明环境的系统。这种需要有custom block这样的plugin。
  • 外部引用支持Bibtex肯定要自己设定plugin。没有几个笔记工具会考虑用户需要做论文引用。
  • 因为不直接支持定理证明环境，很多内部引用系统并不容易使用。
  • 数学公式的输入支持实际上并不友好。
    • 比如某些系统inline数学要求必须用$$, 而普通人inline数学副号应该用单个$。大多系统会有这些对习惯了某种latex方式来说反人类的设计。
    • 几乎都不支持设定全局macro。Quiver是我所见的唯一的例外。

本人现在使用的系统

本人用自己博客的做笔记。

  • 用的是自己的一个markdown版本（和pandoc markdown很像）。支持Theorem Environment.
  • 一个静态网站生成器(hakyll)读取这markdown转换成HTML的程序(pandoc)。
  • 整个编译过程自己还加了一些有用的filter。
  • compile的速度极快。

我现在就是文本编辑器里改改，觉得差不多了保存，手动刷新一下浏览器样子。例子：

单个页面功能上基本完美了。我写东西是在自己的sublime text里写。纯文本编辑体验自然极好。但真实的笔记，不是一切就一个文本。而且，做不到WYSIWYG。

一些WYSIWYG或者WYSIWYM的文档系统

这些系统主要不是为了做知识管理，纯粹是为了创建文档的。
如果用过LyX, TeXmacs或者已经消失的Scientific WorkPlace。会发现这些软件几乎达到了要求。写作和编辑都不怎么费力。其中他们甚至可以直接对做那些公式不改代码的做改动，可怕至极。TeXmacs是里面最成熟的软件，完全可以替代Word。但主要的问题是这个还是单个文档系统，并没有要成为一个真的笔记软件。不过TeXmacs可以很容易的用Scheme写插件，所以理论上来说应该也是可以搞起来。

有些稍微小众一点的软件。Compositor似乎是在DVI输出上面直接做修改。很久以前BaKoMa成功的做到了可以在输出上做LaTeX的修改。

听说SwiftLaTeX是一个能在浏览器里用的\(\LaTeX\) WYSIWYG editor。但是暂时好像用不起来。

这些工具和平台有很大关系。需要下载这些软件，而不适合和其他人协作。

有一个Mathcha的工具，可以说是搬WYSIWYG系统到浏览器里。里面很多设计不错，但整个软件基本功能不够完善。作者后来走的比较偏，花了大量时间去搞画图功能去了。作者也试图做过协作功能，不过迟迟没有出来。

其他

Typst是个试图替代LaTeX的系统。

Fidus Writer似乎是想替代Word，而且主要服务于学术界人士。有点像是一个你写作的所有信息都包括在里面。其中有citation啊之类的东西。

texpad是一个专门写latex的系统。这个系统非常的polished，有很多让生活很舒服的工具。可以从那里面学到不少idea。

数学家的需求

一个notes管理系统

  • 写起来要舒服，无摩擦。比如可以写Markdown+数学部分的\(\LaTeX\)。做任何reference的时候（如定理或者外部citation）应该尽量不要过多手动活动。
  • 记录数学的笔记需要支持Theorem/Proof之类的environment。除了theorem/proof之类的。用户可能会想有自己的block来解决一些问题。
  • 多个笔记的引用和关联非常的简单。可以引用某个笔记里的某个block。（比如某一边引用另一边的定理）甚至embed另一个笔记里的block。(simulate theorem restate package)
  • 基本的版本控制的可能。（不过可能也不重要，因为一年用到一次就差不多了，有可能一个backup功能即可）
  • 可以支持bibtex这样的citation。
  • 类似typora那样，写的东西可以及时看到。只有这样才能提高编辑的速度。

多人协作

现在的数学家的协作方式

  1. 数学家有的用Overleaf。等于把LaTeX搬到了网上。每一个Project有个文件夹。自己可以自己写LaTeX并且在网上preview pdf输出。自己写LaTeX，Overleaf服务器去compile出pdf文件，再显示在用户面前。

  2. 大家共用一个Dropbox。大家在本机上写文章然后compile。也有团队直接用git替代dropbox。

权限管理

这些系统对于权限的管理都来自于给单个Project/文件夹的权限。
每一个Project可以给一些人权限。在这个Project里，任何文件的权限都是完全一样的。Dropbox的Project就等同于一个文件夹。

沟通

如果是多人修改同一个文件。会有一定的沟通问题。Overleaf就有直接的聊天系统。但是有时需要直接指出文件的某个部分。比如作者A没看懂作者B写的这句话，于是加一个comment，表示没有看懂。这样作者B再来看的时候会想应该如何解释。

一般做法是在LaTeX文档里写出这个comment。

有意思的project

tiptap 用来做浏览器里的editor的程序。
Lexical 也是用来做浏览器里的editor的程序。
Mathquill WYSIWYG修改数学公式，可能会比LaTeX好用也说不定。
mathlive 和上面一样.
Kerodon 应该算是一个网络版本的数学textbook, 用了一些有用的技术。
Penrose 用语言画图
SVG Math 解决katex实在太耗dom资源的问题：用SVG。
vditor 算是开源的Typora了。要研究下能否自己写parser。
vale 英文Linter
A Language for Bi-Directional Tree Transformations
LaTeX 相对于 Word 有什么优势？
An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development

【构想】Chickenglass 未来的数学家个人知识管理系统 v0.1

自己开发是没能力弄出Typora那样的东西。我前端能力不行。现有的设想是将现有的博客系统更新一下 + 一个text editor的plugin。作为v0.1的心痛。

  • 在常用的text editor里写东西。服务会监视所有文件的动态。文件改变了，服务就会更新各种meta data，保证text editor可以快速的利用新的数据。
  • text editor的plug in可以写作时快速用起来。比如引用的时候输入[[之后就冒出来一个可以autocomplete的现在可以引用的东西。或者有啥其他快捷键。

这边要更加完善自己的markdown variation。叫Chicken Markdown。和Pandoc Markdown非常像。主要是解决pandoc markdown作者还没有放入他们系统里，或者永远不准备放入系统里的一些syntax。

graph TD
    A{Editor} -->|Update .md file| C{Trigger Build}
    D -->|related meta as yaml| E
    D{Meta Store}
    D -->|Update through plugins| A
    C -->|Update through file| D
    C -->|start compiler| B
    E -->|Pandoc + Pandoc Filters| F[Pandoc AST]
    F -->|HTML Writer + Template + Optimizer| H[HTML]
    B[.md file] --> |Preformatter|E[Pandoc Markdown + yaml]
    H -->|update preview| A
    subgraph Compiler Pipeline
    B
    E
    F 
    H     
    end

估计我这边的做法。

  • 静态网站生成器: 实际上就是一个build系统。可以用Slick(建立在Shake上）。
  • 文件状态监视（很容写）：
    • 输入文件监视+meta rebuild：有改变就跑build系统。build系统并且会更新新的meta data。
    • 输出文件监视+live preview：输出改变之后自动刷新浏览器live preview。自己写一大堆东西再手动刷新的世界告一段落。（可以用livereloadx）
  • Chicken Markdown Compiler：这里将有一整套从一个.md文件到HTML的整个build process:
    • 将chicken md文件变成pandoc md。并且提取meta data。
    • pandoc将pandoc md变成AST。
    • pandoc filters对AST做加工。其中包括theorem environment, numbering。
    • html writer将HTML写出。
    • 剩下一些优化工具对输出HTML做出优化：
      • 将KaTeX输出变成的HTML（server rendering），并且优化其输出。
      • 对整个HTML/CSS等做出一些优化。
  • 自己写个简单的meta data服务：要收集的每个block的信息。每个文章的信息和之间的互相引用。
  • 给text editor增加提高效率的工具：
    • 利用上面的meta data服务，做出不错的autocomplete或者索引功能。
    • 支持chicken md的syntax highligher

优点：

  • 可以用自己最熟悉的文本编辑器。浏览器里什么样的编辑器都不可能和纯粹的文本编辑器对抗。
  • 生成静态页面。输出可以0 javascript。整个架构也无比的清晰。增加新的功能主要是AST->HTML部分做修改。如hackmd上面那么多疯狂的功能实际上就是弄个costom block。
  • 纯文本迁移也不困难。
  • 大多不常用但是需要有的功能也是用市面上常见的工具维持。比如用git做version control。真正需要用到的概率并不大，可能一年来个几次。但是这功能又不能没有。

缺点:

  • 完全无法满足类似typora那样所见所得的问题。（可以当做第一版本，剩下的目标是整个项目搬到浏览器里。）
  • 如果非要用那几个系统，没几个人懂Haskell。之后软件就死掉了。
  • 需要有人能写text editor插件。
  • git也不是人人都会用。

Chickenglass的多人协作系统

没想到怎么搞。应该也是project based。 Chickenglass大概设计是每个人可以开project，整个project设定permission。等同于个人版上加上个权限系统。但是具体的协作还是有一堆要考虑的。

在个人版Chickenglass上线之前不用考虑。

Select a repo