这么多年了，Org-mode 的 Tag 一直不进化，让人用不下去。而且，用 Agenda 来过滤标签，很快就陷进性能瓶颈。
这两天看了 Tana 的介绍视频，以及详细地了解了 Tana 的 SuperTag 机制。
觉得可以基于 Org-mode 基础特性，实现类似 Tana 的 SuperTag 机制。
该包暂时命名为 org-supertag。我会在这里记录关于该包的思考。
11 个赞
SuperTag 的机制：
-
Node。是 Tana 的基本信息单位，基本上一个圆点+一段字符，就是一个 Node。每个 Node 都可以单独展开为独立的页面。
-
SuperTag。Node 因 SuperTag 而变得不同。没有了 SuperTag 的 Node 就是一个圆点+一个字符。
Field。是 SuperTag 机制的核心，扮演 3 个角色：记录属性，命令触发器，AI 启动器。
- 记录属性。在标记 Tag 的同时，为 Node 记录属性。Node + Tag，让 Node 灵活地拥有很多不同的类型，甚至同一个 Node 可以拥有多个类型，适用于多种场景。
- 命令触发器。在 Field 里设置了某种命令后，SuperTag 会变成可点击按钮，点击后，可以让 Node 可以执行某种动作。
- AI 启动器。是命令触发器的变体。搭配 Prompt，点击 SuperTag 后就可以执行 AI 命令，这会非常方便。
- 多视图。Tana 本身具备 List, Table, Cards, Tabs and Calendar 等视图。
纵览以上，可以发现，Org-mode 已经实现大部分 Tana 的基础特性：
- Agenda View：可以过滤/聚合同一个标签的 org-headline
- Property：属性抽屉，则让每一个 org-headline 具备不同的属性，实现不同的记录。甚至也可以做到以不同的属性值作为触发器。
- Column View：org-mode 内置了基于 headline 的 Property 转换成列表展示的方法。
- Tag：尽管 Tag 机制比较残，然而，它居然也已经做好了标签继承的工作。
目前，我已经简单的实现了 Field 的 “记录属性” 的特性：
- 记录属性，让 Property 与 Tag 关联。当前在 Headline 中应用不同的 Field 时，自动添加不同的标签。实现了这个，就可以反过来，设计基础的 Tag 机制——在添加对应 Tag 的时候，同时为当前的 Headline 设置了对应的 Property。
1 个赞
AI 命令 是啥？
一个触发机制，一个 Node 和一个记录了 AI Prompt 的 SuperTag 组合。
此时，可以将 SuperTag 当作按钮，点击后，AI 会自动将 Node 当作输入，然后自动输出内容。
跟你在聊天窗口里的效果差不多。
换言之，此时的 Node 变成了一个可执行的对象。
org-supertag 的第一个应用场景，就是阅读 org-mode 的更新说明。
每一次读起来都非常头痛，完全不结构化。
同一个 org-store-link 的更新说明，散落在不同的地方…
非常需要用 org-supertag 标记好，然后再汇总输出
org-supertag 的数据结构
- 基础类别： file node tag field
- 只有标记了 supertag 的 headline 才视为 node
- node 记录两个属性：node-id、file-path。前者用于标记，以方便追踪。后者则是用于记录 Node 当前所在位置
- supertag 本身也记录 tag-id，该 id 与 node-id 关联
- 一个 node 可以标记多个 supertag
- 一个 supertag 可以标记多个 node
- 一个 node 可以有多个 field
- 一个 tag 可以无需添加 field
- 当 tag 添加了 field，只能与这一套 field 关联
- field 本身不具备 id，它的实例将储存在 node 的下方（以 property 的形式）
- field 通过创建 tag 模板的形式，与对应的 tag 进行关联
- field 的数值，在序列化之后，与 tag-id 保存到哈希表里（由于不是解耦的，所以无需 id）
1 个赞
有点头痛，到底是 哈希表 只用于储存映射关系，还是用 哈希表 储存所有相关的数据？
最终决定，使用 中间表 + 分表 的方式。以适应 org-supertag 多数据实体（file、tag、field、node），多种关系（一对多，多对一），以及未来可能针对新的功能，所预留的拓展性。