你可以在 NetBSD 下用 sixel（
要跑Emacs就已经装Xserver了，这个体量对比下wm几乎不要钱，自己用c撸一个都行。只提供基本的窗口切换功能，然后把控制接口捅到Emacs。相比之下一些elisp包反而很重。
emacs-nox 不需要 x-server
这个体量对比下wm几乎不要钱，自己用c撸一个都行。只提供基本的窗口切换功能，然后把控制接口捅到Emacs。
这个的层主的命题是不使用 X，不是重量不重量的问题。如果允许使用 X-wm，那不是已经有现成的 exwm 了么 
而且如果只显示一个 GUI app 不需要任何的窗口切换功能，是可以只装 x-server 不装任何的 wm 的。
1 个赞
外网上的负面评论不无道理，PGTK 确实只是主要为了纯 Wayland 支持而引入的，而不是在于让 Emacs 有个完美的 GUI。但原作者显然是把既成现状 take for granted 了，然后以一个现代图形用户的眼光和更高的要求做 ta 心目中理想的设想，才写下这样的有点跳脱的文字吧。
我读过来挺感触的，因为确实说中了一些 GUI 的痛点，也很羡慕原作者提出这样一个 manifesto 的勇气。希望 ta 能做出点什么出来，不管怎样吧。
1 个赞
作者对之前那篇文章进行了一个补充性的 FAQ：
这是一个小文章，补充了原始文章，该文章在网上迅速传播。
最初的版本是为一群兴趣相投的朋友准备的，用了一种适合他们的特定口味的方式写作和表达。我清楚地意识到其中一个缺点是我的写作过于冗长。我使用华丽的语言，漫不经心，经常偏离主题。这正是 ADHD 的表现。如果您想完全基于这一点进行评论，可以使用 LLMs 来为您总结这篇文章 ^{[[#footnote-1][1]]}。
在这里我将编译常见的对原始文章的驳斥意见。
** Rebuttals
驳论
**** Text-based widgets are superior to GUI ones
文本式小部件优于图形用户界面小部件
这只是一个历史巧合。GUI 对象可以渲染文本；它们是文本界面的超集。除了自定义工具包之外的所有现成方案都会强制执行其他图形应用程序的偏好，这些应用程序具有显著的语言多样性。它们会被简化，而我对此没有意图。
**** Use Lucid
这是一个朝着自定义工具包方向迈的一步。Lucid 仍然是一个现成的工具包，具有有限的交互模式和动词。
**** Use a terminal
使用终端
这仍然是一个我认为次优的解决方案。某些终端 Emacs 可以弥补 Emacs 的不足。Emacs 作为终端应用程序的表现比大多数程序更好，但这样也只是掩盖了问题。
**** The PGTK build is for systems without X
PGTK 构建用于没有 X 的系统
这或许是最初的意图，但关于 PGTK 的讨论似乎弄乱了局面。 此外，我还要指出，没有 X 的系统数量很多，比如我的系统。 尽管如此，由于 XWayland，PGTK 构建没有给我带来任何明显的麻烦。 这并不意味着没有系统会故意断开与旧依赖关系， /例如/ 不提供 XWayland。 PGTK 在某种程度上解决了这些问题。 这不会在不做出不合理的打包选择的系统上产生截然不同的体验。
**** People with Xwayland do have X
这其中有些是刻板的说法。我理解说在某些发行版上找不到任何 X 兼容性是某种程度上的准确描述。PGTK 构建确实提供了一些在这些系统上可用的 Emacs。PGTK 构建的用户比运行这些系统的用户更多。
因此，我认为准确地说，虽然原始作者可能仅打算使其提供对不以任何形式交付 X 的系统的兼容性，但这并不能削弱其在 X 可用的平台上提供一个远不如体验的事实。此外，选择“纯 GTK”的意图实际上是 GTK 提供了对许多 Wayland 特定协议的“一流”支持。
因此，我认为 PGTK 构建提供了一个在无 X 系统上兼容性方面更差的解决方案。正确的做法应该是将 Wayland 协议的支持添加到 Emacs 代码库中。我打算纠正这一点。
**** GTK is the de-facto standard
GTK 是事实标准
这在某种程度上是正确的。由于 KDE 的发布节奏过于紧张，对 C++^{[[#footnote-3][3]]} 的偏好，缺乏其他系统 ^{[[#footnote-4][4]]} 编程语言具有强大的图形工具支持，以及 GTK 开发人员散发出的傲慢姿态，大多数 Linux 图形应用程序，无论官方还是非官方，如果存在任何前端，都将使用 GTK。
这正是我认为 GTK 2 和 3 之间发生许多变化是完全无视整个生态系统的原因。GTK 的广泛使用给维护和改进它的人们带来了巨大的责任。虽然 GTK 的某些技术方面在第三版本中确实有所改进，但由此带来的不稳定性和许多变化，导致程序们不得不追逐一个“
移动靶”。 这反过来导致了许多项目的资源被浪费。
因此，即使与 GTK 相悖，我坚信这是更多项目应该做出的选择。此外，这样可以防止具有传统设计理念的程序因底层库实现的变化而变得不可读。 由于为 Emacs 的核心图形子程序贡献的人数相对于整个社区来说微乎其微，我认为解决方案必须与不稳定 API 具有少量的依赖关系。
这使得 SDL 成为一个不错的选择，而 GTK 和 Qt 以及 Iced 则是糟糕的选择。
**** This is a massive undertaking
这是一个巨大的工程
这些规模的宏伟事业，在 Linux 基金会的庇护下，是我过去五年中三份工作的主要内容。我曾建立并管理了两个成功的多元化团队，并按时交付了成果。我曾在预算有限的情况下管理项目，但得到了很多善意支持。我不会说我在这方面是最优秀的，我更希望这项倡议由更长时间专门从事 Emacs 工作的人主导，但我绝不是一个未经考验的年轻人。
组织方面由经验丰富的人手负责，我完全有信心认真对待此事。
**** You do not understand X
你没有理解 X
这是一个真理。我有很多不理解的事情。如果以善意的方式进行辩论，并且避免过分傲慢，我很乐意采纳您的批评。
**** But X also does the same
但 X 也做同样的事情
如果它有，我很乐意宣扬它的优点。最有可能的是，它没有。我很乐意从一个已经能做我想要做的事情的代码开始，很乐意听取建议。你知道如何联系我。
**** Let’s just focus on Lem
我使用了这个项目，并祝它一切顺利。我认为它提供的相对于 Emacs 的优势并不能满足我的需求，而且我认为它所要实现的目标不在其发展路线图上。
**** The EAF is a better solution
EAF 是一种更好的解决方案
这篇驳斥文章值得一篇单独的文章。
** FAQ
常见问题解答
**** Q: Why use SDL
为什么使用 SDL
它是一个我花费大量时间研究的库，通常在某些情况下被认为是..
一个现有的 retained-模式 GUI 工具包，如 GTK 或 Qt，是不合适的 该应用程序必须管理自己的事件循环。 该应用程序使用 C-ABI 与系统库链接。 该应用程序预计不会经常更新， /例如/ 专有游戏。
一个成功的应用示例，它使用了 SDL，是用 Common-Lisp 编写的 Lem 编辑器。
或许还有更好的选择，但我坚信它们需要提供显著的优势，才能够被认为是比 SDL 更好的。
**** Q: Why not fix GTK
为什么不修复 GTK
由于 GTK 将会改变，这需要大量的维护。而且由于 GTK 比较有主观性，像 Emacs 中需要的 =Alt= 键绑定等功能，需要以 GTK 不期望的方式来实现。
此外，由于 GTK 不提供必要的工具来开发我们自己的交互动词集。GTK 的` /modus operandi/ `是简洁，这与 Emacs 的需求背道而驰。
**** Q: Would this let me have a transparent background
这个问题不仅仅是图形性质的。但我认为可能创建一个高效的实现，将其暴露给用户，同时保持旧行为作为默认设置，这样那些拥有现有配置的人就不会需要处理难以理解的模式。
同样适用于 shader background 。
同样适用于花哨的文本效果。
同样适用于动画和精美的图形用户界面。
**** Q: Is this going to be big
是的。不幸的是，会这样。目前最好的方法是与维护图形管道的人员密切协调。我们需要将工作提供为可以上游集成到 Emacs 中的补丁集。考虑到 FSF 最近的问题，我对此将版权分配给 FSF 存在保留意见，但我认为，如果它能够默认可用，否则这种东西就无济于事。
**** Q: How will this look
目前，我将分享我的发现并尝试衡量兴趣。 迄今为止，反馈意见一直都非常积极，远远超出了我的预期。
虽然我很想现在就开始着手做这件事，但首先需要就某些架构决策的意图进行讨论。 修复潜在问题最好的方法是理解事情是如何被做出来的。 尤其是，我想花时间逐步分析主循环，看看是否可以修复某些操作的性能问题。 不幸的是，这个问题与 /如何/ 编写大多数 Elisp 代码有关。 解决办法很可能是一个更加庞大的工程。
**** Q: What is the ideal outcome
理想结果是什么
我希望 Emacs 能够像 Electron 那样发挥作用，它是一个编程平台。Dired 既像 KDE Dolphin 这样的文件管理器，而且在很多方面都远胜于它。文本编辑的动词作为整体配置变量。
有一种方法可以让 Emacs 成为托管许多日常使用的程序和应用程序的地方。Elisp 不是我使用过的最好的语言，但它在某些方面比 JavaScript 优秀。因此，我认为一个仅使用自由软件的平台，取代 Chromium，并且能够支持大量的不同交互模式，是长期目标。
我相信 WYSIWYG“办公”风格的编辑已经触手可及，提供了一个更适合专家的用户界面。
我也相信 Emacs 的语法和理念可以应用于图形设计，并且基于 Emacs^{[[#footnote-6][6]]} 的矢量和/或位图编辑器也是完全可行的。
这个问题是图形应用程序的一般困难，特别是 GTK 图形应用程序的困难。
** Footnotes
脚注
^{[[#footnote-reference-1][1]]}
如果你不认为 LLMs 比你的阅读水平好，但仍然想抱怨语言问题，我很乐意收到你的邮件在` =/dev/null= `。
^{[[#footnote-reference-2][2]]}
不幸的是，这带来了很多恼人的后果，例如输入必须在不需要翻译的上下文中进行翻译。我知道 ` =C-i= ` 是大多数终端模拟器发送的按键码，但我认为这并不能阻止对 ` =C-i= ` 和 ` =TAB= ` 的独立绑定。
^{[[#footnote-reference-3][3]]}
但就像 C 语言也同样丑陋，与他们试图摆脱的 C++ 语言一样。
^{[[#footnote-reference-4][4]]}
否则，Java 也是一个强有力的竞争者，以及 JavaScript。
^{[[#footnote-reference-5][5]]}
相信我，兄弟！
^{[[#footnote-reference-6][6]]}
顺便说一下，Inkscape 与 Emacs 许多问题相似。它也正在与 GTK 作斗争，为此而受苦，并且由于单线程导致 UI 迟缓等问题。
1 个赞
期待您的作品发布！
api层面如果提供一个 transient 兼容层 ，推广起来会容易很多。
对我来说支持 Wayland 就是最大的优势，当然也许作者并不这么认为。但是每个人的需求本来就是不一样的。
除此之外其他的观点我都觉得 OK，核心问题并不是 GTK 多么多么难用，而只是对于 Emacs 来说并不是很合适，我想知道有多少人会选择让 Emacs 显示那个默认的菜单栏和工具图标栏。当大部分用户都在用基于文本的 UI 或者高度定制化的 UI 的时候那自带许多 widget 的 UI Toolkit 当然是不合适咯……Emacs 自己实现一个 Toolkit 当然是更好的，但我的评价是天天骂 GTK（或者骂任何自己看不顺眼的东西）代码不会自己长出来……所以我对 PGTK 感到满意。
或者说 Emacs 应该只使用 GDK 而不使用 GTK，但因为我没有仔细的看过代码所以我也没办法对这个想法提供任何实际的建议……
2 个赞
我自己对 Nautilus 没有什么特别不满的情绪，这种基本上还是非常主观的评价吧。
然后如果是支持 xdg-desktop-portal 的程序应该会自动调用 portal 的选择器而不是 GTK 内置的那个，所以如果你不是 GNOME 桌面的话，考虑看看你的程序是否支持 portal？也许就能换成你喜欢的。
xdg-desktop-portal仅适用于部分程序（比如Firefox，Chrome等），对于GTK原生应用还是只能用默认的类Nautilus文件选择器。我个人感觉GTK默认的选择器太简洁了，不像Qt文件选择器可以用树状视图显示文件。