使用 Emacs 作为万能粘合剂

ginqi7 · 2022 年7 月 25 日 11:10

最近一段时间，我编写了几个 Emacs 工具，用于提高工作效率。作为一个 Emacs Lisp 新手，并没有选择编写纯粹的 Emacs Lisp 程序，而是使用 Emacs Lisp 来封装若干 Cmd 工具，把 Emacs 作为粘合剂。总体使用下来，感觉很不错。

想要用 Emacs 来做所有的事情，可能会比较困难。但使用 Emacs 来结合所有的其他工具，是一个很好的方法。

最近为写了几个 Emacs 工具：

leetcode-emacs: GitHub - ginqi7/leetcode-emacs: an emacs plugin to write leetcode programs
hbase-shell-emacs: GitHub - ginqi7/hbase-shell-emacs: A Emacs Plugin for hbase shell
kubectl-emacs: GitHub - ginqi7/kubectl-emacs: This is an Emacs plugin that makes it easier and faster to manage k8s using kubectl.
global-interactive-emacs: GitHub - ginqi7/global-interactive-emacs: Global Interactive Emacs

这几个工具，可以分为两类：

前 3 个工具，把 Emacs 作为一系列命令行工具的 GUI 交互式 interface
最后一个，把 Emacs 做为系统应用快捷启动器的后端。在 Emacs 之外使用在 Emacs 中定义的交互式函数的方法。

使用用例：

希望有兴趣的朋友可以相互交流，提供意见，促进开发。

yaoni · 2022 年7 月 25 日 12:17

很酷，最近我刚开始接触容器，感觉也需要类似的工具。另外这个做缝合怪的思想我也很赞同！

ginqi7 · 2022 年7 月 25 日 12:40

前 3 个工具的核心思想是用 Emacs 作为一系列 Cmd 工具的GUI，处理cmd的输入输出。这样，既能够复用Emacs本身一系列方法和插件，把最常用的方法、工作流抽取出来。另一方面也不用重复造cmd的核心逻辑。

最好是能够抽出一个框架，然后不断的扩展插件。不过目前并没有很好的抽象思路。就先把工作中需要用到的工具，用 Emacs 封装一下。后续积累多了，或许可以抽象出一个核心。

最后一个工具，思路比较有意思。基于，Global interactive Emacs functions | isamert.net 这篇文章的思路。我这边尝试，用 Emacs 作为应用启动器，替代正在使用的 Launchbar

twlz0ne · 2022 年7 月 25 日 13:47

Prerequisites

choose

choose github

README 这里并没有链接可以点。

ginqi7 · 2022 年7 月 25 日 13:52

GitHub - chipsenkbeil/choose: Fuzzy matcher for OS X that uses both std{in,out} and a native GUI 这个链接。之前我把 ssh 的链接附带上了，github 没能解析出来。已经替换成 http 链接。

seagle0128 · 2022 年7 月 25 日 17:04

都是很好的创意👍🏻 Emacs当初命令行在类Unix上都有不错的表现，实现也比较容易，就是性能弱些。

ginqi7 · 2022 年7 月 25 日 17:23

是的，性能可能比较弱。但通常问题不大，把 Shell 放到异步的进程里，让它自己慢慢跑。只要不卡住Emacs，可以不用停止手头的编辑。等结果返回再弹出结果窗口。

DogLooksGood · 2022 年7 月 26 日 06:29

可能 kak 很适合这个想法，kak 的哲学就是连接 commandline 来实现插件

ginqi7 · 2022 年7 月 26 日 16:54

kak 是什么？

ixnij · 2022 年7 月 27 日 00:36

kakoune

Selection-based modal text editor

ginqi7 · 2022 年7 月 27 日 02:32

看定位，类似一个交互式的Vim。但看起来并没有比（vim + 一系列的配置）更有优势的样子。

twiddling · 2022 年7 月 27 日 04:16

感觉不用扩展到拿另外一个编辑器来做类比，我理解 magit， counsel-rg/ag/git-grep 类就是典型的在 emacs 里 “粘合” 命令行工具的实现，比如说 magit 是 git 在 emacs 里的前端，或者就叫 interface ，rg 的结果导入 minibuffer 就可以继续用模糊搜索， occur 等其他工具来操作了（终端里对应 fzf 这类工具）。emacs-anywhere/everywhere 是类似第四个的思路，全局的 emacs popup window。 @DogLooksGood 大佬开发的 emacs-rime 也是对 rime 的粘合了，只不过是和更底层的 librime 库交互，而不是已经封装的命令行接口，与 pyim 的关系就是楼主说的以下用 elisp 实现还是用外部实现的区别

eaf 是和 pyQt 粘合，exwm是和 x window的接口粘合。不知道是不是这么理解？

manateelazycat · 2022 年7 月 27 日 04:29

EAF不仅仅是pyqt和vue的黏合，更是用python，javascript和c++来横向扩展emacs，只不过EAF是以图形为载体的。

从lsp-bridge实践来说，可以借助EAF核心技术实现无界面的python编写emacs插件，这种技术和命令行工具黏合区别是，命令行工具往往都是对字符串输出做正则过滤，很难深度扩展和语法交互。

其实我有时候在想，EAF和lsp-bridge探索出了一条路，通过 “RPC+多线程+elisp/外部语言互相调用” 机制，我们可以构建一套基于 jsonrpc 的通用多语言框架，我们可以用任意语言扩展emacs，elisp专注文本编辑和黏合，所有性能相关的解析工作都交给外部语言，这样会形成所有语言都可以扩展emacs，不仅仅是python，javascript和c++，甚至是golang和rust等，它山之石的生态为emacs所用。

我最近发现比较流行的neovim，在核心机制上居然和EAF有异曲同工之妙，都是通过RPC和外部语言及生态协同开发的思路。

ginqi7 · 2022 年7 月 27 日 05:00

无比赞同这个想法。目前受限于个人 Emacs Lisp 水平，我目前的做法比较简单，把某个 cmd 工具丢到异步去运行。Emacs 做为 input / output 的接口，来进行功能扩展。目前的一大缺点是，输入、输出的格式，不同的命令完全不统一，导致无法进行抽象，只能一个工具一个工具去适配。

使用 RPC 确定 Emacs 与外部交互的协议格式，就如同 lsp-bridge，这样就可以做成一个统一的框架，只需要适配不同的语言/工具时，实现对应协议的适配即可。

ginqi7 · 2022 年7 月 27 日 05:06

全局的 emacs popup window，可能是一个更好的选择。使用 mac 工具 =choose= 作为全局的输入输出有一些局限性。

我看看 Emacs 弹出全局窗口时，能否更好的设定窗口的样式。例如：

进行输入、选择时，只需要弹出 minibuffer
当用户选择完，弹出窗口进行查看结果。

twlz0ne · 2022 年7 月 27 日 06:41

以前也有人尝试用其他语言扩展 Emacs (不是那种需要编译的动态模块)，例如 Pymcs，就跟用一般的包一样 require，然后启动一个 python 进程，用来进行 Python-Emacs 双向交流。虽然当时没有提出 RPC 和多线程的想法，但大致目标是差不多的：在 Emacs 和其它语言之间架一道桥。

可能当时的各方面条件还不成熟，用户的接受度也不怎么样。类似这样的项目大多都废弃了。