考虑到TUI, 最理想的设计还是C/S模式, 类似neovim. 不过emacs这么拆分起来估计有难度.
Emacs官方有意支持类似word的功能, 不知道到时候TUI上这些功能会怎么同步.
GTK绑定到Elisp没用， 图形库没有多线程支持就是残废的， 绑定了也是白费工夫的。
Qt 吓跑一票人，Rust 再吓跑一票人，虽然 Emacs、Vim 都不完美，偶尔卡卡，但是习惯了，忍忍就好，其实一人每天能打多少字呢？搞的太臃肿复杂，一大堆不同技术揉在一起，维护太困难。Linus 本人据说用 uemacs 写代码：kernel/git/torvalds/uemacs.git - Micro-emacs
https://github.com/rsc/plan9port/tree/master/src/cmd/sam Plan 9 上的 VI 等价物 https://github.com/rsc/plan9port/tree/master/src/cmd/acme Plan 9 上的 Emacs 等价物
虽然整个 Plan 9 都挂了，虽然在用十全大补包 Doom Emacs，但还是很叶公这些简单的东西🤣
如果是考虑长期对Emacs的维护和提升， 平台本身选择复杂点没什么，懒猫的计划不是为了短期，这是非常难得的。如果一开始的出发点就设定的比较低，也没有什么意思，无所谓用什么。但如果做整体和系统考虑，事情会很不一样。
GNU Hyperbole 都没人用，就別叶公 acme 了。不用 ed 的人也不会去用 sam。
这确实是个问题，技术栈太多对于开发和维护都不是一件好事。如何达到既满足长期发展又不至于复杂臃肿，达到一个平衡点才好。
从规范简洁来说，qt不知道比emacs内部零散的ugly API要好多少。
7 个赞
与其争辩，不如实干
从UI框架来讲确实如此。