我觉得这篇文章关于 Emacs 界面交互的观点很深刻

Emacs-general
5

一周前在Reddit上看到了相关的讨论，有个用户的评论 我觉得也挺有道理的，摘部分翻译一下中和一下文章里的负面意见吧：

评论里为 GTK 的辩解（Gemini 翻译）

在Linux系统中，图形用户界面（GUI）和桌面环境向来都像是二等公民。自由的Linux世 界只能从企业界获得一些残羹冷饭。当企业界从Unix桌面转向Windows/Mac桌面时，Linux 基本上就停留在了Unix桌面黄金时代的那个技术水平。

Linux桌面社区是一个分裂的社区，并且已经分裂了超过25年。从90年代开始，似乎每个 人，连同他们的七大姑八大姨，都在为类Unix（*nix）系统发明窗口系统和工具包，其中 大多数都受到了X11的启发。

X11饱受诟病，然而，X11在一些基础方面做得非常出色。它也是开源的，每个人都在学习 它，每个人都有自己的想法，都想做一些新的东西。当然，X11也有问题，每个系统都有 问题，但是大家并没有去修复X11，而是每个人都想成为开源和工具包领域的英雄，每个 人都在推行自己的议程。这就是开源的诅咒。大家不是团结协作，而是各有各的算盘，都 想推行自己的理念。结果就是现在这个样子。最终Wayland取得了一些进展，但每个人仍 然需要X11。工具包也不得不为不同的窗口系统维护多个后端等等。

GTK最初只是一个“普通的”X11工具包。后来他们将其移植到了Windows和Mac上，并意识到 需要对窗口系统和操作系统后端进行抽象。最终他们也进入了Web和云领域，意识到需要 进一步抽象，并进行了更多的重构。

这篇文章的作者显然不知道事情为什么会是现在这个样子，没有对历史进行研究，也不理 解要让一个窗口系统和一个工具包正常运行起来所需要的工作。我建议他去查阅一些关于 Java AWT和Swing的旧文章，研究每种方法的优缺点。

像Emacs这样的应用程序有两条路可走：要么走AWT的道路，使用底层平台（Gtk、Qt、 win32等）提供的任何东西；要么走Swing的道路，只使用基本的平台窗口系统（例如 X11/Wayland、win32），然后实现自己的控件和绘图。Emacs是一个非常特殊的应用程序， 它实际上只需要子框架来实现它所使用的那些控件（菜单、菜单栏和按钮），但这意味着 要自己实现它们，可以用Elisp也可以用C语言。这完全是可行的，并且可以跨平台，但对 于那些在乎外观的人来说，与原生系统相比可能会显得格格不入。

然后是文章内容的评论：

GTK was a mistake for Emacs

选择 GTK 是 Emacs 犯的错

PGTK 主要是为了在 Wayland 上支持 Emacs。当然，不借助 GTK 实现 Wayland 支持也是 有可能的，只是那样的工作量会相当大，这也是开发者选择 PGTK（而不是重写）的原因。

The reason why Emacs doens’t feel like a graphical program has everything to do with the fact that GTK doesn’t offer much of anything.

Emacs 不像典型 GUI 程序的原因是 GTK 的不足

这与 GTK、PGTK 等等都无关，Emacs 本就不是为了 GUI 设计的。Emacs 更像是字符渲染 的那种 TUI 游戏，同时适用于无 GUI 环境和图像界面环境。

The customize interface uses textual facsimiles of actual widgets because GTK would simply not allow that level of control from Elisp that you would need.

Customize 界面使用文字效果来效仿 GUI 控件的原因是 GTK 不提供 ELisp 所 需的高度可控的 API。

Emacs 设置界面没有 GUI 化的原因只是因为没有人想去这么做。

译者个人理解：

  1. Emacs 同时支持 GUI 和 TUI
  2. Emacs 下一切均 buffer，包括 Customize 界面
  3. 我们希望 GUI 和 TUI 共用尽可能多的代码，同时不同 buffer 均共用文本渲染代码
  4. 结论：GUI 和 TUI 必然看起来差不多
  5. 除非：有人为了 GUI 而 GUI 去把 wid-edit.el 重写一遍，同时加上大量的 C 代码 提供 (1) 一套对应的渲染代码，(2) 一套仅 GUI 下使用的 ELisp API

下面是个人意见：

  1. 对于 Emacs Customize 这种“文本效仿GUI”的控件界面，我与作者的意见相左。作者认 为这是一种 hack，但……首先从历史上来说，Emacs 诞生的时候还没GUI吧？而加上GUI支 持的时候和TUI保持一致外观也是非常自然的，何来hack 一说？

    当然，让按钮/文本框/各种控件看起来更“GUI”一些这个想法本身似乎没啥问题。但 Emacs 里的文本控件的优势是能够像普通文本一样选中/复制/查找，这是目前我所知的 所有GUI框架（除 contenteditable 外）都做不到的，除非像作者一样打算从头写起。而这也印证了上面所说的：这不是 GTK 的问题。

  2. 用 SDL 提供跨平台功能：

    ……我希望所有打算从头/半从头实现文本渲染的人都能去读读下面几篇文章：

    如果 GTK 不能满足 Emacs 的需求，那么 SDL 作为一个主要用于游戏的库就绝对没法满 足 Emacs 的文本编辑需求，除非继续“从头写起”或是直接放弃BIDI支持。

  3. 再为 GTK 说几句：之前我也在查Rust下的GUI框架，结果发现了 A 2025 Survey of Rust GUI Libraries 这篇文章。总结起来就是大多框架都不太行，唯一一个支持屏幕阅读器和输入法的还是基于Qt 的。 GTK也不支持Windows 下的屏幕阅读器，但至少这几个月的 GTK 4.18 似乎会更新支持（而Linux下则是早就支持了）。

    在 Unicode 更新了好几版的2025年，我的确觉得下面这些要求也不算严苛了：

    • Font fallback，在遇到默认字体不支持的字符时自动根据系统配置查找支持的字体
    • Bidirectional text (BIDI)，中英文从左到右排，阿拉伯语从右到左，支持两种的混排
    • 系统输入法，包括输入以及候选框跟随光标等
    • 屏幕阅读器以及其它无障碍访问功能
    • 跨平台（上面所有提到的）

    但，奈何就是有很多拉丁语系开发者认为字符只有英文和emoji，然后把上面的坑一个一 个踩过来。在这里面，GTK（或是其它有足够历史的框架）虽然有很多历史遗留和各种问 题，但上面几点的支持都还算是做得不错的了。

但 xkcd 真是永不过时： xkcd 927: Standards

2 个赞