跳至主要內容

插件类别理念

LincZero大约 10 分钟

(作者在开发这个插件的一些思考,都记在这了……)

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所有的优点,此外还不需要加代码块和引用块插件如:kanbanmindmap
方式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等插件