跳至主要內容

插件类别理念

LincZero大约 10 分钟

(The author's thoughts on the development of this plugin are recorded here...)

AnyBlock 最容易理解的一个功能就是 List转Table，但这并不是插件的核心，只是一种比较有用的附带功能。

插件类别理念

插件分类

首先我们来分类一下渲染类的插件（我大体将OB插件分为管理类、辅助输入类、和渲染类） 渲染类中：现在大多数的特殊语法解析，有五种

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

他们各自的优缺点

方式缺点优点插件举例
方式1不能进行Md语法解析，
解析语法失效会变得非常难看 ，
不属于嵌套容器，虽然能强行嵌套		可以使用代码解析来着色，适合代码内容。能避免md语法干扰插件如：dataview, mermaid等
反例插件非常多，如：Ad的代码框语法、聊天记录软件(支持Md信息发送版)、里面嵌套有Md语法或图片的所有插件、mindmap(list生成脑图)
方式2每行">"符号和嵌套缩进非常麻烦，特别是内容非常长时
（相较于代码块）		可以使用Md语法解析来着色插件如：Ad的Callout语法
方式3整篇文章使用有方法2所有的优点，此外还不需要加代码块和引用块插件如：kanban，mindmap
方式4因为需要空行作为结束符，一般不能作为嵌套容器，也意味着内容不能有空格有方法2,3所有的优点。此外标识符只需要加在前面插件如：list-callout，
Table Extended的-tx-前缀（不要也行但偶尔出错），
checklist的#todo前缀（这个是全库识别与单独渲染），
AnyBlock的局部和标题选择器
方式5
--------		如果用了嵌套语法由于没缩进会比较难找其实就是方式4的分支。有方法2,3所有的优点。此外加标签只需要加在前后即可插件如：HTML代码、AnyBlock的首尾选择器

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

上面我将特殊语法分为了五大类，然后你们会发现，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语法出来之前，写起来是这样的：

Note

标题

标题2

标题3

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

Callout写法

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

Note

标题

标题2

标题3

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

Any-Block写法

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

写法一：首尾选择器写法

{[code] ad-note

标题

标题2

标题3

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

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

ad-note

标题

标题2

标题3

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

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

[!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原生的表格写法，我为启用列表转表格的列表添加了两项扩展操作：

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

下面我们来对比一下

对比项

例子

源代码可读性

扩展性

书写

表格直接编辑

数据性

ab列表

例子

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

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

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

快

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

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

md表格

例子

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

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

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

中等

可用enhance等插件

弱