可能 kak 很适合这个想法，kak 的哲学就是连接 commandline 来实现插件
1 个赞
kak 是什么？
kakoune
Selection-based modal text editor
看定位，类似一个交互式的Vim。但看起来并没有比（vim + 一系列的配置）更有优势的样子。
感觉不用扩展到拿另外一个编辑器来做类比，我理解 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的接口粘合。不知道是不是这么理解？
1 个赞
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和外部语言及生态协同开发的思路。
10 个赞
无比赞同这个想法。 目前受限于个人 Emacs Lisp 水平，我目前的做法比较简单，把某个 cmd 工具丢到异步去运行。Emacs 做为 input / output 的接口，来进行功能扩展。目前的一大缺点是，输入、输出的格式，不同的命令完全不统一，导致无法进行抽象，只能一个工具一个工具去适配。
使用 RPC 确定 Emacs 与外部交互的协议格式，就如同 lsp-bridge，这样就可以做成一个统一的框架，只需要适配不同的语言/工具时，实现对应协议的适配即可。
全局的 emacs popup window，可能是一个更好的选择。使用 mac 工具 =choose= 作为全局的输入输出有一些局限性。
我看看 Emacs 弹出全局窗口时，能否更好的设定窗口的样式。例如：
- 进行输入、选择时，只需要弹出 minibuffer
- 当用户选择完，弹出窗口进行查看结果。
以前也有人尝试用其他语言扩展 Emacs (不是那种需要编译的动态模块)，例如 Pymcs，就跟用一般的包一样 require，然后启动一个 python 进程，用来进行 Python-Emacs 双向交流。虽然当时没有提出 RPC 和多线程的想法，但大致目标是差不多的：在 Emacs 和其它语言之间架一道桥。
可能当时的各方面条件还不成熟，用户的接受度也不怎么样。类似这样的项目大多都废弃了。
相关连接：
1 个赞
可能多数的 Emacs 用户还是更希望在 Emacs 内部解决所有问题。能用 elisp 解决的问题，不太希望引入其他工具。lsp-bridge 能够完善起来，还是主要是其他的 emacs lsp client 太卡了，生产使用不是太靠谱。才觉得 lsp-bridge 是真香。
对，EAF主要是解决了浏览器集成和PDF渲染性能问题，lsp-bridge主要解决写代码不要卡顿的问题。
如果脱离了核心应用场景，纯粹的多语言编程模型确实很难发展起来。
1 个赞
我居然漏了一个工具：git-emacs GitHub - ginqi7/git-emacs: A Emacs plugin for Git 异步的运行若干 git 命令。主要由于使用 magit 觉得卡，而编写的工具。
1 个赞
感谢答复，我以前用过一段时间的 vim/neovim, 个人感觉是，相比 elisp, vimscript 写起来比较别扭，和 bash 有点像，实现复杂的逻辑会比较麻烦，也没那么有趣，vim 主打的又是它的编辑模式，所以 vim 里插件基本还是围绕文本编辑和 IDE 类的，既然 vimscript 不好写， IDE 类功能性能要求又高，可能反而让 vim 开发者更向外找方法了（个人猜测）。但 emacs 里 org, 邮件啥都有，也都能用 elisp 来写，就把人粘住了。
elisp挺好的，除了性能和多线程确实不行，肯定比vimscript写的舒服，但是面对多线程时，和vim遇到困难是一样的。
neovim RPC方案从效果上看已经非常好了，工具本身还是要看效果，既然elisp没法大变，就接受它作为胶水语言就好，多线程和性能交给外部语言，你看neovim发展不是很好的嘛。
世界是多语言融合的，emacs多语言融合是好事情，融合后更强大，而大多数emacser受自由软件宗教信念影响太大，每天都在用elisp去处理它不擅长的事情，自我限制的风气太可怕。
3 个赞
是，我自己也不是 kak 用户。
不错的想法。我用rofi做app launcher,但是其性能和内存消耗我都不是很满意。见 Rofi slow startup · Issue #1222 · davatorium/rofi · GitHub 如果能用emacs做app launcher我还可以拓展一些额外的功能（如用拼音首字母搜索）。
不过我安装有问题，可能有些额外的依赖。我建议针对一般用户简化一下，如果是通用工具的话，没必要使用第三方的语法糖，如果我没有装用到的第三方库，安装就有问题。
使用 rofi + Emacs 可以在 Linux 做一些个性化的扩展。 我在 Mac 上使用的 choose + Emacs，不过 choose 目前只是一个交互式选择的工具。感觉限制还比较大。后面考虑看看有没有其他的选项可以替换。
前几天我在补全替换 LaunchBar 的一些功能。我自己的日常需求，基本上快要补全了，接下来，我再 review 一下代码，简化一下不必要的依赖和结构。
如果有什么问题，或者意见，欢迎在这里，或是github上给我提出。感谢。
以前写过一个用终端加 + fzf 的窗口选择工具 GitHub - metaescape/xwish: x window interact in bash ， 不过只能切换或者交换 window （app 启动部分我用的是 dmenu），看了本帖后，这两天我还整理了一篇关于这个工具以及窗口管理想法的 blog ：用 FZF 作为窗口切换工具 有兴趣的话可以看看
2 个赞
我最近练手的两个 package 可作为你的思路的补充 :
- macOS 上的 app switcher 。作为练手，小弟写了一个package macfa-mode : 让 Emacs 具备切换到 MacOS 其他 application的能力
- emacs 上的 google translator . 作为练手，我写了一个 package : trans-mode, 集成 translator 到 emacs 中
可以看看 rofi-in-elisp