插件类别理念
（作者在开发这个插件的一些思考，都记在这了……）
AnyBlock 最容易理解的一个功能就是 List转Table，但这并不是插件的核心，只是一种比较有用的附带功能。
插件类别理念
插件分类
首先我们来分类一下渲染类的插件（我大体将OB插件分为管理类、辅助输入类、和渲染类） 渲染类中：现在大多数的特殊语法解析，有五种
- 大都在代码框里做，比较著名的就是Ad的代码块语法 （感觉Ad的代码框当“特殊引用块”的做法就有点难受了，甚至会觉得Callout是上位替代品）
- callout是在引用框里做，其他的没见过
- 整篇md文章作为语法的解析，例如 Kanban
- 前缀方式，从前缀标识到空行为止的区域作为特殊语法格式的区域。优点是这是表格的超集，完全兼容传统表格的语法
- 标签方式（
不过现有接口没有直接支持，如果要实现这种方式，就得自己重写一套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有两种方式做到这一点：
此外，AnyBlock还将降低开发难度
- 原本想要实现一个代码块以外的特殊语法解析程序，可能非常困难（例如你想做个和callout语法相似功能的插件） 但你可以选择AnyBlock作为前置插件，提醒用户先安装该插件，你就可以只用实现OB提供的代码块注册模块，而不用实现其他复杂的东西！
- 文本处理器可以叠加使用，即可以复用组件，处理器之间松耦合，有的环节可以使用现有的工具，而不再需要自己造轮子
插件类别理念 - 为什么要用AnyBlock？
为什么要用AnyBlock？ 前面说了原理，可能不太直观，这里举几个可以使用AnyBlock优化原有插件的例子。
callout杂谈
前面的优缺点可能不那么直观，现在看一下实例： （请反复切换 源码、实时、渲染模式 查看这一节内容）
Ad插件写法
在callout语法出来之前，写起来是这样的：
Callout写法
在callout语法出来之后，写起来是这样的：
Any-Block写法
用Any-Block（本插件），写起来是这样的（写法非常自由）
写法一：首尾选择器写法
{[code] ad-note
标题
标题2
标题3
- 一个普通的列表
- 一个普通的列表
- 一个普通的列表
- 一个普通的列表 }.
- 一个普通的列表
写法二：块转化写法（如果ob不支持callout语法，可以这样写，但ob 0.14支持了，现在就没必要了，这里仅供演示）
写法三：标题选择器写法：
[!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列表 | 例子 | 极高，且在单元格内容较多时表现更出色 | 允许嵌套md 暂不允许左右中对齐 允许一定程度合并单元格 | 快 | 新插件，暂时没有，但理论上可扩展做到 | 强，数据和显示分离， 未来制作导出为数据的扩展都很方便 |
md表格 | 例子 | 极高，但在内嵌长文本（如图片或大段文字）表现不佳 | 允许少量md样式 允许左右中对齐 使用插件table-extend才能合并 | 中等 | 可用enhance等插件 | 弱 |