插件类别理念

插件分类

首先我们来分类一下渲染类的插件（我大体将 OB 插件分为管理类、辅助输入类、和渲染类）

渲染类中：现在大多数的特殊语法解析，有五种

1. 大都在代码框里做，比较著名的就是 Ad 的代码块语法 （感觉 Ad 的代码框当“特殊引用块”的做法就有点难受了，甚至会觉得 Callout 是上位替代品）
2. callout 是在引用框里做，其他的没见过
3. 整篇 md 文章作为语法的解析，例如 Kanban
4. 前缀方式，从前缀标识到空行为止的区域作为特殊语法格式的区域。优点是这是表格的超集，完全兼容传统表格的语法
5. 标签方式（不过现有接口没有直接支持，如果要实现这种方式，就得自己重写一套 md 后处理器，好了，写出来了）

他们各自的优缺点

为什么大部分插件都通过代码块实现？

上面我将特殊语法分为了五大类，然后你们会发现，OB 的语法解析类插件大多数是通过方式一实现，为什么？

可能这些特殊语法需要被包括起来、正文无关、害怕特殊语法的格式会被误识别（需要避免被 md 语法解析），这些都是原因。

但有的插件明显是不利于用方式一来实现的，但他们依然会使用，例如：Ob 未支持 callout 语法之前的 ad 插件，就是一个绝佳的例子

（没有贬低这个插件的意思，ad 插件也对 callout 语法提供了大量的支持，可以通过命令快捷插入 callout 语法（不是 ad 语法），设置面板可以同时扩展 ad 语法和 callout 语法的类型，都是非常好用的。像 BT示例库 就利用了 ad 插件扩展 callout 语法类别的方式，区分了每个块的 class 类型，从而进行扩展）

目前大部分的插件都能通过代码块渲染特殊格式的一个很大的原因，是 obsidian 提供了一个很方便的 api 接口：

this.registerMarkdownCodeBlockProcessor("chat-qq", (source, el, _) => {
    new Chat_qq(source, el, _, this).render()
});

只要实现这么一处接口，就可以轻松在实时和渲染模式中实现局部文本在特殊格式下渲染

语法块转化

但正如前面所说的，各种解析语法的 选择器 (这里将选择特殊语法范围的方式称为选择器) 都是各有弊端和长处的。

AnyBlock 做的，就是混淆这些语法的选择方式。无论是引用块选择、代码块选择、前后缀选择、还是其他方式。都能通过 AnyBlock 互相转化

AnyBlock 有两种方式做到这一点：

1. 通过 块转化 功能，将不在代码块内的文本假装成是在代码块内。 你可以通过该方式处理几乎所有的使用代码块的插件
2. 插件开发人员可以使用 AnyBlock 提供的 新接口，注册新的处理器来处理

此外，AnyBlock 还将降低开发难度

1. 原本想要实现一个代码块以外的特殊语法解析程序，可能非常困难（例如你想做个和 callout 语法相似功能的插件） 但你可以选择 AnyBlock 作为前置插件，提醒用户先安装该插件，你就可以只用实现 OB 提供的代码块注册模块，而不用实现其他复杂的东西！
2. 文本处理器可以叠加使用，即可以复用组件，处理器之间松耦合，有的环节可以使用现有的工具，而不再需要自己造轮子

插件类别理念 - 为什么要用 AnyBlock？

为什么要用 AnyBlock？

前面说了原理，可能不太直观，这里举几个可以使用 AnyBlock 优化原有插件的例子。

callout 杂谈

前面的优缺点可能不那么直观，现在看一下实例：

（请反复切换 源码、实时、渲染模式 查看这一节内容）

Ad 插件写法

在 callout 语法出来之前，写起来是这样的：

### 标题

### 标题2

### 标题3

- 一个普通的列表
  - 一个普通的列表
    - 一个普通的列表
  - - 一个普通的列表

Callout 写法

在 callout 语法出来之后，写起来是这样的：

Any-Block 写法

用 Any-Block（本插件），写起来是这样的（写法非常自由）

写法一：首尾选择器写法

{[code]

ad-note

标题

标题 2

标题 3

• 一个普通的列表
  • 一个普通的列表
    • 一个普通的列表
  • • 一个普通的列表 }.

写法二：块转化写法（如果 ob 不支持 callout 语法，可以这样写，但 ob 0.14 支持了，现在就没必要了，这里仅供演示）

[quote2code]

写法三：标题选择器写法：

[!note]

标题

标题 2

标题 3

• 一个普通的列表
  • 一个普通的列表
    • 一个普通的列表
  • • 一个普通的列表

列表转表格 list2table

这是 AnyBlock 自带的一项比较好用的功能，仔细想想，该功能的实现是否正正是依赖于 AnyBlock 的范围选择再处理的能力？

固然可以将列表内容放入代码块内再渲染，但是不是就没那么好用了？

题外话一

其实作者是先想到了要实现 列表转表格 这一插件，然后思考如果要实现这一插件会有什么问题，然后才总结了各种插件进行“特殊语法解析”的方式，才提出了 AnyBlock 这个插件。提出了 “首尾选择器” 和只需要标注头部的 “列表 引用块 代码块 标题 等选择器”

题外话二

在实现这个插件之前，其实还有两种方式来实现 列表转表格 的功能。

一种是 Bosidian群群友@九炎 写的纯 css 实现。缺点是……略丑

（不需要头部标识不算较于ab的优点，其实anyblock也可以不需要头部标识选择列表。将设置里的 `总是选择` 开启就行，但强烈不建议）

（这里透露了一点实现细节：AnyBlock不是先选择的头部再选则下面的，而是先选择块，再看上面有没有头部信息的）

另一种是我用 dataviewjs 硬写的模拟。缺点是没有真正合并单元格，用 ^^ 符号来假装单元格被合并了

chat-view-qq（with md）

再来举点用处：

比如我之前写了一个聊天记录插件 chat-view-qq，能快捷记录聊天对话

我后来想要将说出来的话可以以 md 格式被渲染，这个效果我可以做出来，但会有一个问题：

在代码块里写 md 代码会非常奇怪，就像 ob 不支持 callout 语法之前的 ad 插件的写法

BT 示例库版 callout 优化

BT 示例库里，很多 callout 扩展效果用 AnyBlock 来写，语法上会更加简单（不需要为了方便 css 选择器选择而去使用不太方便的写发）

例如时间线、多分栏、等等。

折叠或压缩长代码

在 AB 插件自带的很多处理器上，你都会发现，这些处理器处理的范围如果只能写在代码块或引用块里，都不会那么强大。

例如：自动折叠代码块、或代码块超长时自动折叠一部分、代码转文档等。直接在代码块上面写上处理器就能做到很好的效果，简单快捷

列表转化理念

AB 的核心能力是范围选择并处理，但很多人对该特性缺乏了解。

反而更多人可能会因为列表转表格或其他树形图而使用 AnyBlock，所以有人可能会疑惑这插件为啥不叫 List2Table 或 List2Tree。

从功能上讲，列表转化依赖于 AnyBlock 选择器，是一种功能扩展。

但从开发者的实现意图上，列表转树类结构也确实是 AB 插件的核心之一。

共性 - 树结构

树结构是一种很好用的结构，人类可读性非常高，看起来也很清晰。

列表可以表示一种树结构，还有很多东西可以表示树结构，例如有一定限制的可跨行合并的表格、一定限制的流程图、\

一定限制的思维导图、括弧包含图、树形树状图，等等

那么为什么不能让他们互相转化呢？

代替 md 表格

在我看来，ab 扩展的列表远比 md 的表格好用。

为了完全代替 md 原生的表格写法，我为启用列表转表格的列表添加了两项扩展操作：

• 可以用 | 进行内联分隔，就像表格一样（未来可能能支持其他内联分割符，如 :、&、/|*/）
• 可以在第一行前面加上 > 表示表头

下面我们来对比一下

[list2mdutT]

• 对比项
  • 例子
  • 源代码可读性
  • 扩展性
  • 书写
  • 表格直接编辑
  • 数据性
• ab 列表

  • 例子

    [2table]
    - 测试1|测试2
    - 测试3|测试4

  • 极高，且在单元格内容较多时表现更出色

  • 允许嵌套 md 暂不允许左右中对齐 允许一定程度合并单元格

  • 快

  • 新插件，暂时没有，但理论上可扩展做到

  • 强，数据和显示分离， 未来制作导出为数据的扩展都很方便

• md 表格

  • 例子

    |测试1|测试2|
    |---  |---  |
    |测试3|测试4|

  • 极高，但在内嵌长文本（如图片或大段文字）表现不佳

  • 允许少量 md 样式 允许左右中对齐 使用插件 table-extend 才能合并

  • 中等

  • 可用 enhance 等插件

  • 弱

讨论

若阁下有独到的见解或新颖的想法，诚邀您在文章下方留言，与大家共同探讨。