需求剖析
2026年7月22日，Charles Choi在日常任务中，用GitHub issues跟踪问题，却倾向于用Org Agenda管理事务，手动复制GitHub issue到Org文件。他想自动化此过程，文章将展示Emacs可塑计算能力，也是之前《[在Emacs中，一切皆服务](./in-emacs-everything-looks-like-a-service.html)》的后续。自动化操作有两个关键问题，一是想达成的目标，包括将GitHub issue复制为Org任务、主要在Emacs操作等；二是不想做的事，如安装或编写GitHub客户端等。
规格规划
明确需求后，决定利用GitHub命令行工具 [gh](https://cli.github.com)，其好处是GitHub认证由 `gh` 处理，Emacs可把 `gh` 当作GitHub的REST服务。还可使用不同Elisp包和程序完善工具，如用 [Transient](https://www.gnu.org/software/emacs/manual/html_node/transient/) 和 [Variable Pitch Table (vtable)](https://www.gnu.org/software/emacs/manual/html_node/vtable/) 实现菜单和显示功能等。
功能实现
上述功能作为 [fj](https://github.com/kickingvegas/fj) 包发布，源代码在 [fj.el](https://github.com/kickingvegas/fj/blob/main/lisp/fj.el) 文件。`fj-request-issues` 函数通过 `gh` 获取GitHub issues，抽象程度高，操作不到20行代码。返回的哈希表结果处理后填充vtable，用户可浏览issue列表并查看详细信息，还编写了相关命令和函数，可通过Transient菜单访问。
可塑计算观察
由于Elisp是动态编程语言，函数可在运行的Emacs会话中编写和评估，无需重启即可原型设计，与静态语言构建的工具形成对比。Emacs提供多种编辑和评估Elisp代码的方式，加载的代码可临时组合，借助高度抽象功能，实现所需功能代码量少，`fj.el` 约400行代码。他花2.5小时实现基本功能，后续满足需求和重构代码。
软件范围与百分比轶事
[90/90规则](https://en.wikipedia.org/wiki/Ninety–ninety_rule)和 [帕累托原则](https://en.wikipedia.org/wiki/Pareto_principle)在软件开发中有体现，结合 [有界输入有界输出（BIBO）稳定性](https://en.wikipedia.org/wiki/BIBO_stability)，若功能在可交付的20%范围内，可能更快获得预期结果。但对满足大量用户需求的工具开发者来说不常见，如微软Office产品定义有问题。讨论产品定义要区分供应和需求，仅供应商提供的软件开发者承担重任，可塑软件用户可自主调整，开发者和用户角色界限不明显。
为1或N而构建
为1个用户和为N个用户构建软件范围可能相差大，选择为他人编写代码会引发错误处理等问题。可塑技术允许实现“足够好”的功能，鼓励为1个用户构建软件，对仅供应商提供的软件为N个用户构建必要，对可塑技术构建的软件是选择。
可塑软件与用户自主性
在Emacs中实现 `fj` 简单，可利用Elisp包和外部应用程序，一天内有满足需求的工具，无需许可和特权材料。现在在Emacs中可轻松浏览GitHub issues、复制issue到Org文件等，可塑技术赋予个人自由。
结束语
本文探讨Emacs可塑计算能力，通过 `fj.el` 示例展示复用代码和程序创建新功能，合理预期下可塑技术能构建难实现的工具。
链接
-
- 《[什么才是真正的软件臃肿？](https://hardcoresoftware.learningbyshipping.com/p/077-what-is-bloat-really?s=w)》，作者Steven Sinofsky。
[emacs](tag/emacs.html) [org mode](tag/org-mode.html)
[在Emacs中，一切皆服务 ->](in-emacs-everything-looks-like-a-service.html)
 agent和组件)