补充一些信息： steel (一个嵌在rust的scheme实现) 作者已经初步实现了一个用steel扩展helix的分支：
相关配置项：
根据Pascal Kuthe在helix matrix里的说法，他们打算自己实现一个scheme
这些其实是tree sitter的query文件，不是scheme
这个编辑器试了很好用，尤其是那个多光标编辑惊艳到我了，但不习惯vi模式，可以接受纯insert模式，但是硬伤就是plugin语言还没实现。
其实 vim/neovim 的扩展性也很强，vimscript 太难写了，但是 lua 写起来简单很多，在我看来大部分时候不比 emacs 的扩展性差。除了 advice 的这个系统（配合全局命名空间），作为黑客用来 hack 的玩具，advice 这个东西的强大之处无法替代。scheme 有类似 advice 之类的东西吗？
https://srfi.schemers.org/srfi-173/srfi-173.html
https://srfi.schemers.org/srfi-20/
对有反射的编程语言来说根本不难实现
写RTL emacs/vim都会用，谁方便用谁，插件两者都被删除到基本的5 6个了。
我自己应用来说，一般都是用一些简单的，定制的文本处理，当成一个有GUI的脚本语言。viml基本没啥问题，还挺好用; 基本不会用一些复杂的插件; （我自己使用场景上，emacs/vim目前是做得很方便的，VSC/ATOM/SUBLIME等咋方便实现类似的东西，估计因为人菜，一直没整明白）
插件语言既要方便简单，方便随手做一些事情;又要强大满足很多用户各种需求; 这个平衡还是很难把握，或者倾向那一侧吧;
helix确实不错，开箱即用，neovim和emacs配置起来太麻烦了
neovim 还是算简单的，有很多辅助插件，每个插件提供的选项也能覆盖大部分情形。
过一段时间估计更好用，还在成长成熟中， 工具的定位就是要好用，提高效率
抛开生态不说，rust + scheme > c + elisp 乎？ emacs 之前最大的痛点应该就是单线程的设计。rust + scheme 在这一点上能否彻底解放lisp系语言的生产力呢？
大家都看重新技术的好处，但是大大轻视了惯性的力量。
emacs现有生态插件非常强大，不是新技术可以替换的。
还有一点，nvim的插件新的层出不穷，老的很容易被作者放弃，要维护一份一直可用的配置不容易。
确实，生态不能替代，比如org-mode，很多特性都和emacs深度绑定的，我看相关讨论 Org mode plugin · Issue #2825 · helix-editor/helix · GitHub 即使实现一个，很多org-mode具有的特性也是支持不了的
也是代价问题，如果好处或者长期收益远远大于代价，或者可以兼容直接用，还是很有前途的
Org 支持受限其实很正常. 因为 Org 确实很难完整支持, 为了支持 Org 还得单独提供一份 ELisp 运行环境 不成?
Emacs 的魅力在于 Lisp 的定位就是 Emacs 的编程语言，而不是所谓的扩展语言，离开了 Emacs Lisp ，Emacs 连很多非常基础的编辑功能都没有，如果 Helix 做不到这一点，那么我认为不能。而从 Helix 目前计划的实现方案来看，未来大概率还是 Rust 为主导，如果要全面转向 Lisp，显然直接使用一种高性能的 Lisp 方言重写 Helix 要比使用 Rust 编写一个 Scheme 解释器再用其重新实现 Helix 大部分功能要优雅且方便得多，更何况目前 Helix 计划使用的 Steel Scheme 即便是使用了 Rust 来编写，性能也就和 Python 一个水平，比起现在的 Emacs Lisp 都差一个数量级，还有很长一段路要走。
哪怕性能只有 Python 那级別，也比没有多线程的 Emacs 强了，Emacs Lisp 实现里的技术债太多了，比如 Elisp 文件如果第一行不是注释，就不能启用 lexical-binding，这事的结论是在整个重写 Lisp parser 前修不了。
Emacs Lisp 有性能可言吗？