New Emacs 构想

Emacs-general
1

NeoVim这几年“Vim核心+新UI”的发展模式非常迅猛， 要比Vim进化的更快， 在图形和性能方面也不输VSCode。

EAF/lsp-bridge也通过实践证明， 引入新的图形库、多线程等技术能极大的提升Emacs的用户体验。

同时， Emacs社区中一些抛弃Elisp插件生态的做法都很难得到Emacser的支持， 比如RustEmacs， EmacsNG等。

Emacs目前的Elisp插件生态非常强大， 但同时也因为历史包袱的原因在下面几个核心问题很难改进。

  1. 多线程： Elisp全局的变量函数访问特性是Elisp插件开发效率快的关键， 也是很难支持多线程事件循环的拦路虎
  2. 图形化： Emacs采用底层图形库编写多平台代码的做法， 因为缺乏跨平台的控件支持， 开发生产效率很低， 因为某个平台的开发者贡献代码并不能熟悉所有平台的技术细节
  3. GC性能： 单线程加上GC效率不佳， Elisp对象太多就会引起GC频繁回收垃圾对象， 产生明显的卡顿现象

今晚和 @DogLooksGood 聊了一晚上， 我们想了一个New Emacs的技术架构方案：

  1. 多线程/图形库/GC性能解决： 引入Rust/Qt的技术栈， Rust能够很好解决多线程、执行性能和GC问题， Qt能够解决跨平台图形绘制的问题， Rust/Qt的主要定位是做为New Emacs的前端
  2. 保留Elisp生态： 把Emacs本身当作Elisp解释器来用， Emacs跑所有现有的Elisp插件， 插件的图形化主要是反映在文本着色和Overlay处理， 这可以通过本地RPC的方式把Emacs Overlay全部发到Rust/Qt前端上， 由Rust/Qt来绘制编辑器内容， Emacs和Rust/Qt的文本同步由text diff来实现。 这样实现， 一来不用改Emacs本身代码， 二来也可以跑所有Elisp插件
  3. 引入其他生态： 比如浏览器生态、Rust、Python、JavaScript生态， 这一点， EAF等项目已经充分验证可行性

这样做的代价是：

  1. 需要花时间把Rust/Qt绑定弄得和PyQt那样成熟
  2. 需要写一个Elisp插件把文本和Overlay高效的从Emacs端发给Rust进程， 并由Qt渲染
  3. 需要把EAF的一些核心技术， 比如多个Window显示同一个Buffer的镜像渲染代码移植过去

以上主要是阐述了一下New Emacs发展方向、Emacs限制、解决方案和实现代价， 这样实现相比EAF的好处是， 所有平台都可以实现完美的前端效果（包括macOS)。 从我个人的经验看， 完全是可以实现的， 其中关于兼容Elisp生态的想法是 @DogLooksGood 提出来的， 相对于EAF来说是一种理论上更好的方案， 发出来和大家讨论讨论。

63 个赞
2

qt很难接受啊…

3

qt是目前唯一个可以实现浏览器窗口分屏后，两个窗口是一个浏览器内容的图形库。

同时用了qt也可以使用web渲染。

gtk或者其他图形库都太弱了。

4

好奇的問一下; 為什麼很難接受? :eyes:

5

赞！

我个人的建议是

  1. 核心模块需要比较精炼，比较小，不需要像EAF那样上来什么都囊括了，可以给大家来开发的空间。
  2. 第一个release 的版本可以很简单，但能让大家来上手用起来。目前看来要实现多个核心功能，Rust + Qt 更像是垂直的两个开发方向，不知道能不能先只做一个，类似neovim那样，先提供一个terminal上非常好用的Emacs？ 或者就想holo-layer 那样，作为图形库的一个版本。
6

终端版本的我估计我不会做， 我平常除了敲命令以外很少用终端， 但是欢迎像NeoVim那样有各种各样的前端。

目前我个人的状态确实是比较圆满的状态， EAF, lsp-bridge, holo-layer已经让我很舒服了，而且这些增强插件完全不用动 Emacs 源码。

@DogLooksGood 昨天晚上说的想法确实很好， 我觉得Emacs也可以像 NeoVim 那样进化， 兼容所有Elisp插件的关键就是把 Overlay 全部都绘制好， 这样大部分Elisp文本插件就可以正常工作。

7

赞！EAF的很多功能都眼馋，苦于macOS效果不太理想，如果所有平台都可以实现完美的前端效果（包括macOS)就太好啦

4 个赞
8

终于要从根子上下手了呀 :wave: :wave:

QT 觉得可以呀，问题是只要跨平台的支持能简单稳定就好，EAF 我也是很馋，但是平时三平台都可能要用，部署起来有点麻烦，跨平台稳定性也不够，只能是尝尝鲜

9

这个工作量还是比EAF大的， 最近时间都太少， 这也不是一人之力可以做的， 只是发出来和大家分享一下。

确实是EAF之外另外一种大幅提升Emacs体验的思路。

10

看上去不太合适

11

其实并非是 New Emacs, 只是一个类似 emacsclient 的东西. 然后把一些 UI 的计算部分托管到新的 client 上面来。比如说，代码着色，在 emacs 自身中关闭，就可以让文本编辑 buffer 有很大的性能提升。这样一来原本 emacs 的负担就会更小，GC 更少更流畅，二来在新的 client 上面也可以画更酷的 UI 效果。

14 个赞
12

感觉这种方式的话，是很可以的。前后端分离以后, emacs可以专心做编辑逻辑上的事情，渲染上的事情交给前端就好了。感觉说不定还可以像skynet那样多开elisp的虚拟机（当然，只有一个主虚拟机能操控ui, 其余虚拟机做逻辑运算）。

13

双手双脚支持，之前也看到懒猫大大在图形方面的做的尝试。

14

不否认qt可能是同类软件中最好的一个，可能是跨平台的首选，但qt有一个缺点，就是太庞大了，而且不同版本间还有兼容问题（可能是以前某次用qt让我留下了这种刻板印象，不知道现在是否有改进）。

1 个赞
15

见上一条^^

1 个赞
16

都用rust了，不如直接参考neovide用opengl从头撸一个

17

对于绘制文本编辑器、图形和浏览器的特性上， Qt可以做到跨平台一致。

Qt庞大来说真是有偏见的， Emacs这种各平台自己写一大堆没有设计的图形API， 靠开发者毅力而不是规范设计的软件才真是臃肿的呀。

6 个赞
18

考虑这个问题的时候要从经济学的角度去思考， 如果是自己重新做一个不兼容的编辑器， 想用什么都可以。

但是考虑兼容Elisp生态需要考虑两个事情：

  1. 最小化改修改Emacs代码甚至不改Emacs代码就可以兼容Elisp插件生态
  2. 前端基础设施的工作量， Qt在跨平台， 统一绘制、字体渲染以及Emacs Buffer/Window镜像渲染都有很好的生态， 如果从 OpenGL 去渲染， 这些都要从头来写， Emacs就是自己要造一个跨平台图形绘制库， 导致自己进化的包袱太重了

开发者思考问题太喜欢从 “技术选型能否体现我牛逼？” 的角度去思考了， 而生态的构建要考虑经济成本和别人的学习成本， 以及现有软件生态的成熟度去考虑。

8 个赞
19

个人觉得用Rust/QT比pyQT好。用Emacs必须保留elisp插件生态，否则没有太大意义。这个思路棒 :+1:

1 个赞
20

PyQt的好处是Qt绑定最完备， 可以先实现原型。

Rust/Qt的代价就是要花半年时间把 Rust/Qt 绑定好好弄好， 让它稳定。

4 个赞