AnkiLink 完全体构想

AnkiLink 完全实现,必须依赖有块级别 ID 绑定的编辑器。目前来看,思源笔记天然具有这个优势。

AnkiLink,之所以叫做「Link」,改名的时候就有考虑过。那就是双向性。
AnkiImporter 是起点而非终点,AnkiLink 不仅仅要实现从「文档」到「Anki」,还要实现从「Anki」到「文档」的双向链接。

目前对于导入,将 AnkiIn 单独抽象出来成为一个库之后,加入思源格式的 json 解析只是加一个 Parser 的问题,可以说兼容非常好做。
而主要难点就集中在如何获取需要导入的内容,这个大概率要用到思源内部的数据库查询。
HTTP API 未开放之前,应该都只能观望。更具体地,对性能有要求,那么要查询的就是「有某种特殊标记的、在某个特定时间后被更改过的块」。

思源内部的「属性」为配置提供了绝佳平台。AnkiIn 库本身也已经实现了配置功能,再加一层转换,将思源的属性转化为 AnkiIn 的配置,就能无缝对接了。
这样一来,原本写在内容中的强干扰的配置就被屏蔽了。

为了性能,不可能解析导入所有潜在的块,而要进行配置。对于这个问题,AnkiIn 加入了 skip 配置项,设定是否要跳过当前块。只需要将默认值设为 true,然后手动设置 false,就能做到选择性导入。
此外,还有一个树形依赖的问题。在 AnkiIn 的 Markdown Parser 中,对语义树进行了从上到下的搜索,而将父亲节点的配置顺延到儿子节点中,同时让儿子节点重载配置项。这意味着,如果沿用这个模式,我们必须拥有在思源中找到最顶层的有效节点的方法。
在 Markdown Parser 中,根节点天然是文档本身,而以块为粒度的思源结构却有希望做到更细化的程度。但这并不是简单的事情,所以可能还是要采用从最顶层节点开始遍历的方案。但还有一条路:自下向上地遍历。

在与思源的对接中,需要注意的是:修改内容的模式发生了变化。往常的 AnkiIn 的工作模式是这样的:写好一个文档,然后转换它。但是在 AnkiLink 中,我们希望能随时随地修改内容,并且随时随地更新。也就是说,碎片化的读写操作取代了原本的文档式的读写操作,如果依然使用整个文档粒度的导入,那么效率是非常低下的。
但我们前面提到了,我们配置了 skip 功能,**那么只要标记规范,实际上可以极大程度避免这个问题,无效的向下遍历会被快速剪枝,事实上需要遍历的只是有标记的子树。**但这样的效率有一个前提,**就是我们必须能以树形结构获取数据。**也就是说,我希望获取某个节点的儿子、父亲是谁,却不想要它的儿子、父亲的所有详细数据。
**基于文件的数据获取是没有这种优势的。**如果我们依然使用文本获取数据,那么不幸的是,为了获取树形结构,我们必须对整个文件进行读入、解析,最终回到了起点。所以我们还需要等待 HTTP API.

我们的使用场景可能是这样的:在 100 个文档中,每个文档修改了 1 个错别字。如果为了一百个错别字,就要将 100 个文档都从头解析一遍,我觉得这是不可接受的。
所以我的期望是这样:我们知道这一百个文档都修改了 1 个错别字,将这个错别字块找出来,然后寻找他的祖先,继承他祖先的所有属性,再回到它本身。
这样一来,对于一个小修改,我们只需要 $O(h)$ 的时间复杂度,只需要遍历树高个节点。
当然,这依然存在不足:如果节点们拥有同样的祖先,却依然反复查询获取,反而凭空增加了复杂度。自下而上的溯源会有这种弊端,但这是可以避免的。只需要在内存中做一个简单的缓存就能解决这个问题,虽然不是那么完美。

对于 Anki,我们将思源笔记的块 ID 直接存放在 Anki 的卡片中。当思源中发生了内容变更,我们只需要寻找对应的卡片,进行相应的修改。如果找不到相应的卡片,就进行添加。而对于删除就困难一些,因为我不知道思源是否会保存被删除的块的历史。如果没有的话,删除这一块,我希望留给 Anki 端来做。

还有一个困难,就是将思源格式解析为 Html,或者 Markdown 也可以。如果没有什么官方提供的方法,我可能又要手写一个 Parser…预计只会支持到与 Markdown 同等级的语法。

做到这些之后,我们就可以实现思源笔记与 Anki 卡片的单向同步。只需要定期进行一次检查,看看有没有新增的块,再进行内容同步。这样,一个简单的单向同步就完成了。

而 Anki 到思源就更繁琐一些,我们必须从 0 开始。更具体的,我们希望做到在修改卡片的时候,修改的卡片内容能够同步到思源。
首先的想法是,通过 ID 很快可以找到卡片与思源对应的块,然后替换内容就可以了。但替换内容不是说说那么简单,将 Html 重新转换为思源格式,也并不是个简单的活。
思源官方实际上已经做过这样的事情了,希望后续沟通一下,可以避免重复造轮子。具体地,我们可以将 Html 转化为 Markdown 再转化为思源格式。而后者,在思源 1.2 升级时已经有官方的轮子了。

为了实现这个功能,必须使用 Anki 插件的形式进行开发。这触及到了我的知识盲区,但学习应该并不困难。我们的逻辑很简单:修改,同步,仅此而已。

还有上文提及到的删除,如果不能在思源修改时删除,那么就在 Anki 打开时自检验即可。对于所有从思源导入的卡片,我们依次查询对应的 ID 是否存在。一下子又多了好多个查询,感觉性能会很差。但考虑到日常生活的数据量,$O(n \log n)$ 的时间复杂度应该还是游刃有余。但通过 HTTP API 进行查询的话,恐怕还是有些延迟。
考虑到删除卡片是稀有操作,是否值得牺牲如此性能来实现,我觉得需要再次考虑。直接不写删除功能也是一种可能。


UPD: 事实上思源已经偷偷支持了简单的 HTTP API 了,见 https://github.com/88250/Stairway-To-Heaven/blob/main/index.html

可以准备上手开发。