这一切始于一项例行任务。我使用GitHub问题来管理我所有的公共项目，但我更喜欢在Org Agenda中跟踪事情。为了将两者调和，我通常会手动将GitHub问题复制到Org文件，通常是标题和描述，就像一个动物一样。尽管存在这种分离，重复的问题让我能够将其用作我可以在Org中表达的任何事情的临时记事本。因此，我在Org中将重复的问题用作专门的笔记区和一个“暂存区”，用于撰写我想在公开问题中分享的后续评论。我手动复制的时间长到不愿意承认。重复在Emacs中执行任务足够多时，必然会有这样的想法：“我应该自动化这个。”这篇文章讲述了我如何自动化这个任务，并在此过程中强调了Emacs的可塑计算能力。它还应被视为我早期文章“在Emacs中，所有事物看起来像一个服务”的后续内容。要求 在任何自动化工作中，一个基本的问题是“我想完成什么？”我希望能够：轻松复制GitHub问题（标题、描述、一些元数据）作为可以在日历视图中跟踪的Org任务。主要在Emacs中工作，以减少Emacs与网页浏览器之间的上下文切换。用Org语法表达我的想法。创建一个新的GitHub问题。避免处理GitHub身份验证。从Emacs中，在网页浏览器中打开GitHub问题。另一个基本问题是“我不想做什么？”安装或编写一个功能齐全的GitHub客户端。过多担心本地（Emacs）和服务器（GitHub）状态之间的同步逻辑。花费太多时间在这方面（理想情况下在一天内完成，有没有超过一周）。规范 在上述要求确立后，下一个问题是“我如何构建这个？”对于这个特定的练习，我决定利用我现有的GitHub命令行工具gh。这样做的好处是：GitHub身份验证委派给gh；无需直接在Emacs中处理它。Emacs可以将gh视为对GitHub的REST服务，如下图所示。为了完善我们的工具，我们可以利用不同的Elisp软件包和程序：对于用户界面，使用Transient和Variable Pitch Table（vtable）软件包分别用于菜单和显示。org到Markdown翻译将使用ox-gfm。Markdown到Org的翻译将使用Pandoc。将使用Elisp原生JSON支持来反序列化来自gh的JSON响应。实现 上述实现被发布为包fj，其源码可以在文件fj.el中进行检查。值得注意的是，函数fj-request-issues完成了通过gh检索GitHub问题的任务，如下所示。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ( defun fj-request-issues ( repo ) "请求REPO的议题。" ( let* (( fields fj-browser-fields ) ( cmd-list ( list "gh" "--repo" ( format "'%s'" repo ) "issue" "list" "--limit" ( number-to-string fj-request-issue-count ) "--json" ( string-join fields "," )))) ( json-parse-string ( shell-command-to-string ( string-join cmd-list " " )) :null-object nil ))) 请考虑fj-request-issues提供的高水平抽象：命令列表cmd-list形成请求（在这种情况下，是调用gh的参数）。shell-command-to-string将请求发送给gh。返回的JSON响应由json-parse-string处理，以将JSON反序列化为Elisp哈希表。以上所有操作在不到20行代码的情况下完成。返回的哈希表结果随后被处理，以填充如下所示的vtable。从vtable中，用户可以浏览问题列表，辅助窗口更新以显示所选问题的详细信息。针对上述要求，创建了多个命令和函数来处理该哈希表。它们可以通过下面显示的Transient菜单访问：可塑计算观察 由于Elisp是一种动态编程语言，以上函数（或其某些变体）可以在运行的Emacs会话中进行编码和评估。在Emacs中，原型代码行为是常规做法，无需重新启动它。与那些使用静态语言构建且没有可扩展性的工具形成对比，后者必须应用编辑-编译-调试开发周期来测试行为，前提是源码是可用的。Emacs提供了多种编辑和评估Elisp代码的方法，包括：一个临时缓冲区 一个Elisp文件 一个Org源码块 IELM REPL Eshell eval-expression（M-：）由于加载的Elisp代码之间没有隔离，所有代码可以以即兴的方式共同编排。任何可以通过shell访问Emacs的程序进一步增加了这种组合。提供高抽象，因此需要编写的代码量可以很少。在撰写本文时，fj.el大约有400行。