（作者在开发这个插件的一些思考，都记在这了……）

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

标题1

标题2

标题3

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

Callout写法

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

Note

标题01

标题02

标题03

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

Any-Block写法

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

写法一：首尾选择器写法 (弃用，换用mdit语法)

{[code]
ad-note
#### 标题1

#### 标题2

#### 标题3

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

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

ad-note

标题11

标题12

标题13

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

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

[!note]
#### 标题1

##### 标题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等插件	弱