想知道现在Emacs的GUI是如何发展的

casouri · 2018 年7 月 23 日 03:47

除非商业公司全力开发，不然只能想想。或者全世界emacs用户联合起来捐助一个专项基金搞这个

manateelazycat · 2018 年7 月 23 日 03:49

你知道 webkit 这个东西不能常驻吗？ webkit 常驻会泄漏内存除非下次重启（我是用操作系统做了几年的实验的，真金白银）

这也是我为什么不看好底层是 webkit 的IDE, 上面能跑JS, 能通过 CSS 作出很好看的界面，确实不错，但是 webkit 的内存管理机制不适合长时间使用的软件。

casouri · 2018 年7 月 23 日 03:50

这个是苹果（谷歌）的设计问题吗？

manateelazycat · 2018 年7 月 23 日 03:56

webkit 设计的时候就是为了网页应用做的，所以从底层到上面，并不会针对常驻程序进行内存管理，所以非常适合网站和web应用（比如网易云音乐），反正用完一定要关闭。

但是常驻程序就不行，时间长了除非重启进程，否则内存根本无法回收。

我就举一个最简单的例子， ChromeOS该是世界上最拥护 HTML5 OS 的操作系统了吧？它的window manager, 底部任务栏，都不是html5做的, 这是为什么？大家想过没有？

为什么苹果， Google, 微软这些最熟悉浏览器开发的厂商，不把 Mac/iOS, Android, Windows的操作系统任务栏和基础组件用 html5/js 重写？内存管控就是最为关键的原因。

回到 Emacs, 我认为 WebKit/Chromium 是非常好扩充 Emacs 能力的东西，大家都离不开Web了，但是千万不要用 WebKit 来构建 Emacs 的渲染基础，那真是性能和内存管理的地狱。

netjune · 2018 年7 月 23 日 04:04

是的, 这个工作量是超出了emacs目前的开发资源(人手确实有限, 只能一点点慢慢发展)

LdBeth · 2018 年7 月 23 日 04:20

比较好奇背后的原因，因为据我所知给编程语言加个垃圾回收不是多难的事，甚至有现成的库可以复用，HTML5 说白了就是具有一定交互功能的数据结构，和 PDF 的原理应该是差不多的，有什么特殊的理由不能使用垃圾回收吗？

manateelazycat · 2018 年7 月 23 日 04:36

WebCore 底层的缓存机制, session 管理, 以及 WebView 都会不同程度的内存泄漏, 平常开一个几十上百兆的网页根本就感受不到, 但是如果你用 html5 做一个任务栏这种长时间会加载不同图片的程序, 就会发现内存泄漏在稳定增长
JavaScriptCore 这一块是重灾区, 几乎只要用 JS , 然后常驻不关闭, 一定会内存泄漏
如果混合语言编程, 比如 JS 调用 C/C++ 等编程语言库, FFI引用指针就又会泄漏很多

如果只是论图形渲染的复杂性和界面效果, WebKit 是世界上最复杂的图形库, 比 Qt 以及 Gtk 都要强很多, 但是 WebKit 同样是非常复杂的图形库, 它可不是简单的像PDF, 读取文件片段, 然后转换层图片画出来, 等不用的时候, 释放掉图片内存就完了.

WebKit 的问题是太复杂了, 你没法判断哪些东西是真正要释放的东西, 特别是 Web 开发都非常强调缓存来加速的概念, 所以很多内存无法控制泄漏不是因为技术原因, 完全是复杂度和Web的生态环境导致的.

当然, 没有技术上搞不定的问题, 只是如果WebKit的厂商不用它作为常驻程序, 这些问题很难根治, 原来在深度的时候, 我们自己维护了一个 WebKit 分支, 专门用于处理内存管理, 跨编程语言混合调用, X11集成, 本地DND支撑等分支, 但是最后太恐怖了, 上游根据Web的发展方向改代码, 这种专门为了常驻程序开发的分支, 根本就无法合并.

你们知道为什么我一直反对用Web来构建大型软件的绘制基础了吧? 现阶段, Web为基础构建的大型软件, 随着软件复杂度的增加, 性能损耗(同样绘制一个文字, cairo 是最快的,因为它只绘制一层)以及内存泄漏管控将是这些大型软件发展的终极瓶颈.

manateelazycat · 2018 年7 月 23 日 04:43

同样, 我认为Emacs的编程绘制其实并不需要 WebKit 的技术, 就是简单的文字绘制, 根据抽象语法树overlay关键词, 最多搞点语法提示的边框/行号/智能补全的菜单足以, 这些效果本地的 Gtk/Qt/Cocoa 都可以很容易实现.

Emacs的问题不是一定需要WebKit来渲染内容, 而是它底层的图形渲染实现性能太低导致的, 随便一个本地的图形库都可以让Emacser够用.

而且一段文本和图片的渲染, 2D 的 Cairo/QPainter 都比 WebKit 要渲染的快很多, 你们可以比较一下一个本地的终端模拟器的启动速度在 50ms 以内, 一个 WebKit 的启动速度和渲染速度是比不上 2D 图形库的, 原因是绘制的内容就很简单, 文字, 图片嘛, 再先进的技术总不可能突破本地显卡混合的物理极限吧, 一个绘制多层的代码是不可能比只绘制一层的快.

WebKit 是好东西, 是补充Emacs能力的关键, 但不要以WebKit为基础构建所有的东西. Facebook, Airbnb 很多公司都打脸 Html5 本地客户端了.

LdBeth · 2018 年7 月 23 日 04:49

说明 Web 已经点歪科技树了，只能砍了重练。

manateelazycat · 2018 年7 月 23 日 05:10

其实 WebKit/Chromium 挺强大的，也许未来内存都是TB级别的时候，大家都不在乎那点内存泄漏了吧，哈哈哈

tumashu · 2018 年7 月 23 日 08:22

以前听说一个作家，好几十年就用一个dos下面的文字处理软件，用他的话说，就是功能不多也不少，正好。。。。。

Fucmacs · 2018 年7 月 23 日 08:34

相同的问题换到TB级内存肯定只会更糟，GC一次延迟不知道大到哪里去了。Moz用Rust开发的新的浏览器内核也许会作出一些改进。

anon70527524 · 2018 年7 月 23 日 08:34

George R. R. Martin:

manateelazycat · 2018 年7 月 23 日 08:44

用了这么多年Emacs, git里面淘了几百个插件，但是平常用的就那么几十个，经常用的就那么十几个。知识学好了，心平静了，啥工具都顺手。

最切忌的是手里握着倚天剑，却浮躁的没法静下心来雕凿自己的作品，享受专注。

tumashu · 2018 年7 月 23 日 09:01

同意这种观点，也许这也是 emacs 扩展性的体现，我只写小说，我就不需要补全编程语言的功能。。。。

Qquanwei · 2018 年7 月 24 日 08:21

羡慕那种大师。把一个工具用到极致，融进自己的血液中。

但是各位。。。楼已经歪到不知道多远了。。。

ReimuXMX · 2018 年7 月 24 日 12:43

我发现现在几乎所有的关于所谓「上古编辑器」和「现代编辑器」的讨论最终都会歪到这个问题上：

该不该用Web技术做桌面应用？

netjune · 2018 年7 月 25 日 12:01

如果一个软件复杂到失控也是挺恐怖的, 没有真正搞过webkit, 没法进一步评论. 只是它的渲染能力和性能还有跨平台能力, 确实很出色. 将继续关注VS code, 也许微软会对这个东西有所影响.

netjune · 2018 年7 月 25 日 12:11

性能上, emacs也没法充分使用多核啊, 倒是想让它多用一点. 消耗更多的性能, 提供更出色的体验(当然, 两者之间保持平衡), 这才是好的发展思路.

netjune · 2018 年7 月 25 日 12:16

最主要是确实离不开web了, 在两个最常用的应用程序之间的切换跟在同一程序里键盘与鼠标频繁切换一样影响效率.

现在是终端, emacs, 浏览器三个组合, 使用频率最高, 没法再优化了. 总不能转行去当作家吧?