（发布）Org-SuperTag 5.0 发布：架构重构 & 纯 elisp 实现

Emacs-general
1
  • 架构重组：
    • 移除 Python 后端 (simtag/) → 纯 Emacs Lisp
    • 基于数据的新架构，使用 supertag--store
    • 单向数据流（Action → Ops → Transform → Store → Notify）
    • 代码减少 ~53%，性能提升
    • 简化部署，无外部依赖
  • 统一模块结构：
    • 将模块整合到单一职责文件中
    • 移除循环依赖
    • 提高内聚性与可维护性
  • 自动化系统 2.0：
    • O(1) 规则索引
    • 多动作规则与计划任务
    • 关系汇总与公式字段
  • 捕获系统：
    • 基于模板的节点创建
    • 智能字段填充与交互式增强
  • 查询系统增强：
    • 重命名为"query-block"
    • 改进语法与时间操作符
    • 动态表格输出，结果可点击
  • 用户体验改进：
    • 移除实验性功能
    • 统一快捷键绑定到 C-c s
    • 添加完整的英文与中文文档

org-supertag 新旧版本架构对比

代码量对比

版本 代码行数 说明
旧版 ~29,973 混合了 Emacs Lisp 和 Python
新版 ~14,165 纯 Emacs Lisp 实现

新版代码量约为旧版的 47%，在完全移除 Python 依赖的同时，保留并增强了核心功能。

1. 核心哲学：从分散到统一，从命令式到数据驱动

旧版架构虽然功能强大，但其设计更偏向于传统的、分散的命令式模型。各个模块（如 node, tag, db）各自维护自己的状态和操作，模块间直接调用，形成了一张复杂的依赖网络。同时，它依赖一个外部 Python 进程 (simtag/) 来处理 AI 相关功能，这引入了跨语言通信的复杂性。

新版架构则进行了一次彻底的哲学升华，其核心是数据中心化 (Data-Centric) 和单向数据流 (One-Way Data Flow)。

  • 单一真相源 (Single Source of Truth)：整个系统的所有状态都被收敛到一个全局的、可预测的 supertag--store 哈希表中。这消除了数据不一致的根源。
  • 严格的控制流：任何对数据的修改都必须通过 supertag-transform 函数，这就像是数据进入数据库的唯一网关。这保证了所有修改都是原子性的、可追溯的，并且能够触发一致的事件通知。
  • 纯 Emacs Lisp 实现：新架构完全移除了 Python 后端，变成了一个纯粹的 Emacs Lisp 包。这不仅简化了部署和维护，还通过消除进程间通信（EPC）的开销，极大地提升了性能。

2. 架构对比：关键设计点演进

特性 旧版架构 新版架构
核心理念 混合的命令式和面向对象风格。 数据中心化 & 函数式：将数据作为一等公民，操作视为对数据的变换。
数据存储 两个独立哈希表 (--object, --link) 分别存储实体和关系。 单一真相源：一个统一的、嵌套的哈希表 (supertag--store) 保存所有应用状态。
状态管理 分散式。状态可能被不同模块直接修改。 集中式 & 不可变风格：所有状态变更通过唯一的 supertag-transform 函数，保证原子性和可预测性。
控制流 模块间直接函数调用，依赖关系复杂。 单向数据流：严格遵循 Action -> Ops -> Transform -> Store -> Notify 流程，组件间清晰解耦。
模块化 基于功能划分，但模块内职责混合（数据、逻辑、UI）。 基于职责分层：清晰的 core (数据管道), ops (用户意图), services (业务逻辑), ui (交互) 分层。
外部依赖 重度依赖：需要完整的 Python 环境和 EPC 桥接进行通信。 轻量 & 原生：纯 Emacs Lisp 实现。AI 等功能通过 gptel 等标准 Emacs 包集成。
AI/RAG 实现 在外部 Python 进程 (simtag/) 中实现，通信复杂。 原生在 Emacs Lisp 中实现 (supertag-rag.el)，简化了技术栈并提升了性能。

功能变化

新增功能：

  • supertag-capture：增强的信息捕获功能
  • supertag-automation：升级的行为自动化系统（原 org-supertag-behavior）

迁移中的功能：

  • supertag-completion：自动补全标签

移除功能：

  • 探索视图（org-supertag-view-discovery）
  • Python 后端（simtag）及其 AI 和 RAG 支持

改进功能：

  • 标签系统：增加了标签 extends 的方
9 个赞
2

这代码量，牛的！

3

试用下，原来的也很好用了。 这文本是AI写的吗 :grinning_face:

4

用org-supertag-query 提示了Wrong type argument: commandp, org-supertag-query

5

2025-09-07_06-22-04_screenshot
2025-09-07_06-22-04_screenshot2034×454 61.9 KB

6

我有点迷惑。你的 src block 不完整，你是删除了 :results raw 吗？

image
image2412×662 83.8 KB

7

可以 M-x toggle-debug-on-error 再看看这个报错的详细是什么吗？

8

解决了，麻烦更新一下。

9

嗯还是上次我犯的错误，不过是copy你github上的readme :star_struck:

10

没有没有，是我犯了个低级错误，忘记 require 这个 supertag-ui-search 包了。

11

厉害了，产量很高呀！好奇elisp替换python居然性能提升了，是因为架构原因吗？

12

太牛了，直接减少了一半的代码量 :+1:

1 个赞
13

因为 RAG 方法，用向量嵌入的方式太重，资源消耗很大。

所以我现在实现 RAG 的方式是，直接用 LLM 生成检索数据库的语句（org-supertag 已内置），然后返回对应的数据给 LLM，这样子整体轻量很多，而且 RAG 效果不错，相关性较强。

当然性能增强不光是因为移除了 Python 依赖，主要还是优化了框架。

2 个赞
14

牛逼的！

我个人也对基于向量索引的方式做 RAG 不是很感冒。我也觉得基于 search query syntax 的方式更加靠谱。

claude-code gemini-cli openai-codex-cli 等新出的 agent 代码工具都放弃了 向量RAG 转而使用最基本的 grep 工具来自主探索代码库，我个人也认为是有道理的。

RAG 的优势就是比起 grep 更省 token。只有 cursor 这种按月固定付费，且需要调用第三方模型的，才会去做 rag，千方百计的省 token。

15

其实你用一下阿里出的 Qoder 就知道，找代码准不准，和向量化的关系不大。

我觉得 Cursor 的向量化的目的并不是为了准确找到对应的代码。

最近传出 Cursor 将自己的数据作为训练数据集销售的消息…

16

大概扫了一眼，你是用gptel来做LLM，加上RAG？看起来项目还挺复杂，不过使用还是很智能的。有计划上melpa不？

17

是呀，原来是用自己独立实现的 Python 后端连 Ollama 和 RAG 相关的服务，好累……就不重复造轮子了， Gptel 已经很成熟。其实之前是想深入了解 RAG，所以相当于自己动手实操了一遍。

暂时不知道上不上 Melpa，如果要我写文档…就真的不想上了…

1 个赞
18

[5.1.0] - 2025-09-11

功能特性

实现标签管理的交互式模式视图

引入 supertag-schema-view，这是一个专门用于可视化和管理完整标签层次结构的缓冲区。

该视图完全交互式，允许从单一界面直接操作标签和字段模式。

分层显示特性

  • :extends 关系以缩进树形结构显示，提高清晰度

交互命令

添加标签：

  • a：添加新的顶层标签

在标签上操作：

  • n：新建字段
  • e：设置扩展
  • d：删除标签

在字段上操作：

  • r：重命名
  • d：删除
  • M-up/M-down：重新排序

用户体验增强

  • g：智能刷新，保持光标位置
  • j/k/p：标准导航键，提供熟悉的 Emacs 风格浏览体验

一致性改进

字段重新排序功能（M-up/M-down）也已添加到节点视图（supertag-view-node.el）中，以确保一致的用户体验。

1 个赞
19

5.2

添加了数据库自动备份的机制，默认会备份最近 3 天的 Copy。

1 个赞
20

每次后台搜刮的时候会卡Emacs，v4时没这么严重