放弃 TUI 是合理的。
“对比而言，TUI 的画面注定是简陋的。” 选择 TUI 的用户应当要有这样的心理预期。既然使用了 TUI，就不要有过多的追求。
这是事实，neovim和vim的 TUI和 GUI不能说一模一样也可以说基本毫无差别。
兼顾tui和gui 就意味着基本上做不到 fancy 的 GUI 了。
目前emacs 的tui我觉得唯一的怨念就是没有真的浮窗（overlay不适合用来做常驻浮窗、bug很多）其他都还好。
可变字体，内嵌图片之类的东西在TUI里能不能实现可以说想都不用想了好吧。。。
新的定型文
放弃 XXX 是合理的。
“对比而言，XXX 的YYY注定是ZZZ的。” 选择 XXX 的用户应当要有这样的心理预期。既然使用了 XXX，就不要有过多的追求。
5 个赞
基本毫无差别取决于个人的期望值，如果你想的是图文混排，这个确实不好做到。
Neovim 的 TUI 和 GUI 基本一模一样，原因主要是官方的 TUI 做的确实不错，大大压缩了 GUI 的升级空间。另外即使在成熟的跨平台 GUI 框架下开发出定制 view，重绘 statusline、completepopup、float win、virtual text、cmdline。。。等等，工作量仍然不小。
随着开发三年的 extmark range 特性近期合并完成，Neovim GUI 的发展可能会走向类似 jupyterlab。主体采用官方 view，ext range 与 GUI 控件双向绑定，完成图片、视频、3D 等内容的呈现和互动，互动内容会回写回 editor view。这是比较经济的做法。
猫哥别急, 我想大家都是希望能让Emacs 更好, 而很多人像我一样, 都只是在用Emacs, 对Elisp还不太习惯, 大家出发点都会有些局限. 对于我这样的初级用户,能用Elisp实现一些自己想要的功能, 能用起来,就很开心, 因为hack Emacs 本身, 尤其是享受Elisp hack emacs 的便捷, 也是喜欢用Emacs的原因.
考虑一下 Mogan Code
我们社区已经计划开启 Mogan Code 这个项目，作为墨干理工套件的一部分。而且我们最近几个月验证了将墨干编译为WASM在浏览器里面使用的可行性：https://mogan.app/
2024年夏天，我们社区会发起至少两个开源之夏的项目，完善Mogan Code相关功能。目前只是Kick Off。我刚刚全职投入墨干的开发（作为一个独立开发者），近期主要还是在开发Mogan Research（用于学术写作）。后续会把Mogan Code这个项目正式启动起来。
- 保留Elisp生态： 把Emacs本身当作Elisp解释器来用， Emacs跑所有现有的Elisp插件， 插件的图形化主要是反映在文本着色和Overlay处理， 这可以通过本地RPC的方式把Emacs Overlay全部发到Rust/Qt前端上， 由Rust/Qt来绘制编辑器内容， Emacs和Rust/Qt的文本同步由text diff来实现。 这样实现， 一来不用改Emacs本身代码， 二来也可以跑所有Elisp插件
GNU TeXmacs的架构和Emacs是一样的，需要兼容Emacs的api，这样Elisp插件就可以用了。这个技术架构的1，3都已经没有问题了，主要工作量是兼容Elisp生态。
2 个赞
我的GNU TeXmacs的Fork，Scheme实现用的是更加成熟的 S7 ，一切都是现成的。只是缺一群开发者来参与，打造Mogan Code!
其实 neovim 是有大量 GUI 可以做到的事情（至少emacs都可以做到的）在目前都距离实现遥遥无期的：
可变字体 图文混排 多个 frame （多个 frame 主要的意义是可以放不同的显示器）
单窗口内可变字体是做不到的，多个 frame 是可以的，可以有不同字体，放不同的显示器。好几个 GUI 都实现了，特性叫 multigrid。
图文混排基本不用指望，按照我对特性的理解，inline image 技术路线基本放弃了，更可能走 notebook 演进路线。
- 楼主所构想的将Emacs作为Elisp解释器用是像上图这样吗？
- 前端考虑通用性、性能、生态，是不是也可以考虑 Electron
Electron的内存占用太大了吧？
嗯， 你可以New Server当作 lsp-bridge 这样的 Python 后端。
可惜不是 rust 
一些复杂的插件, 比如 lsp client 或者 org-mode 之类, 运行过程并不只需要 ELisp 解释器本身, 同时需要 Emacs “标准库” 提供的各种函数去进行 (创建窗口) + (改变窗口布局) + (创建overlay) + (改变原有buffer字体/背景色) + (显示图片) 等等一系列操作.
要让它们正常工作的话只是同步 highlight/overlay/text 可能不太够, 需要实现 Emacs UI 标准库某种程度上的一个兼容层, 替代掉 Emacs 提供的各种函数, 发送到 Qt 这端执行. 这个工作量感觉还挺大的, 而且和现有的 Emacs 逻辑绕在一起, 可能比较混乱. 不知道有没有比较好的解决方法.
不过如果能确实梳理出这么个兼容层, 以后说不定会自由很多, 比如很方便把臃肿的 Emacs 替换成一个精减版 Emacs kernel 之类.
6 个赞
lsp client可以像lsp-bridge那样完全不需要emacs计算，emacs只做渲染就好了。
org-mode我觉得可以更进一步，完全用新的前端去解析和渲染，一举解决不能渲染嵌入多媒体的问题。
剩余其他文本编辑的插件都可以收敛为elisp解释器和overlay模拟层。
6 个赞
orgmode的解析似乎只有org-element.el一个完整的解析器，其他语言的orgmode parser都功能不完备。解析的事情目前看只能用org-element.el。
1 个赞
观察各个产品对编辑器图形库选型是个很有意思的事。有意思在于新兴的编辑器都没有一个de facto的库。
- VSCode用的是JavaScript
- Onivim现在用的是JS，但Onivim2去改用revery了
- Sublime之前用的是Skia，觉得性能不够直接OpenGL搞起
- Neovide倒是在用Skia
Qt除了Qt Creator有没有别的编辑器项目？
前几天在 IRC 上聊到 Emacs 支持多线程的话题，觉得和这个话题多少有关，
起因是我觉得 lsp-bridge 宣传得还不够，就在 IRC 里推广，然后有人看到是用 python 写的，就说“什么时候 python 的多线程也能当卖点啦”
我就说，不就 GIL，有啥好黑的，不说 python 已经在准备去除 GIL 了，emacs lisp 连 GIL 都不配有呢，因为多线程功能连 python 都不如。
这事情搞笑就在我连电脑上 python 装都没装，而黑 python 的家伙应该是经常写 python 的。
然后就有 emacs 开发者现身说法同意我，说 emacs lisp 多线程从定义上来说也是 GIL，因为同时只能运行一个线程。
然后我接着补充，emacs lisp 顶多算协作式多线程，然而大部分已有代码完全是在单线程的前提下写的。
中间插入一个我最近遇到的因为多线程不够协作，wanderlust 在显示 IMAP 下载的 HTML 邮件链接的图片时两个下载线程会导致互相锁死的 bug。这bug还是因为我给Emacs 29的 shr 加了图片链接白名单，可以在邮件显示可以信任来源的图片才触发的。因为我确定除了我以外没人会触发甚至懒得去报bug。
然后有人问，就不能把常用的包比如 gnus 用多线程思路重写么
然后那个 emacs 开发者的意思就是，这些功能是不可能光靠有足够的用户就能完成更新换代的，大部分普通用户不足以从技术上支持 emacs 的开发。
这就是我对 New Emacs 的看法。
我可以确定的是，哪怕是 Emacs 核心包的维护者，也不一定掌握那个包的全都功能，Emacs 28 就出现了 Gnus 把标题独立解码成 GBK 等编码的支持代码清除了导致没法正常显示中文新闻组的惨事，等我意识到的时候都正式发布了已经太晚了，把功能加回去的事也不了了之。这事对我冲击太大结果现在还在到处提。
再顺带吐槽个事，有用户报 bug 说 todo mode 编辑会卡死，emacs -Q 能复现，然后我作为不用 org 的 todo mode 日常用户和 package maintainer 看了半天发现他为了强迫症让所有日期用 ISO 格式把打印日期的函数 advice 了，然而 todo mode 压根没有考虑过日期可以是 ISO 格式的。他用 advice 过的函数创建的错误格式 todo 文件用 emacs -Q 打开，也算 emacs -Q 能复现了……
当然从 EAF 的成功来看，首先懒猫是这样的肝帝，如果没有对实现细节过度乐观的话我觉得还是足够支撑起这样一个分支的开发的。
26 个赞
一个建议，标题改成 qt-emacs构想，这样标题与贴子内容更加相符，不至于产生误解，new emacs 这个名字可能会产生不必要的争论
3 个赞
rust 
emacs