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

Emacs-general
65

im的界面基本是固定的, 不需要什么渲染

???

照着你的发展思路, emacs发展到最终级别, 很可能跟eletron的体积和性能一样

这正好不是我的思路，我的思路就是编辑器不需要复杂渲染，只需要渲染好等宽文本。

照你的发展思路，Emacs 最终集成 electron 以后只不过就是默认键绑定不一样的 atom 和 vs code，没什么存在的必要⋯⋯

66

已经说过了，emacs上游不准备停留在这种状态，类似office word的所见即所得功能是创始人推动的一个功能，其他开发者也在尝试xwidget版本。不一定变成eletron，但是你的想法没法实现了，现在功能已经超越了你的发展思路，比如非等宽字体很早就支持了，而且还支持同一buffer里同时显示不同字体和不同大小字体，还有buffer里显示按钮，图片，链接等等，这些都是所见即所得的基本功能。所以继续讨论好像没什么意义。不说了。

67

对于 Electron，又爱又恨，恨比爱多，个人非常讨厌 Electron。

Electron 的应用普遍颜值较高，这个我挺喜欢的。 但它吃 CPU，吃内存，每次 htop 一看，排在前面的要么是 chrome，要么是 Electron 应用。 有的 Electron 应用，比如 Slack 等，搞个 css 动画转一转，在 Linux 上 CPU 直接 100%，非常伤。

目前阶段还是更喜欢基于 GTK QT 的程序，webkit 还需要再加把油。 感觉 webkit 等 web 技术的未来可能在 Chrome OS 上？（偏题 + 个人感想）

68

这无所谓，RMS 本来就是个怪人。但是 GNU 的人肯定是不会用 Electron 的⋯⋯

69

@MetroWind What’s your logic?

70

These wordings make you cool. I adore you very much. :face_with_monocle:

Update(Maybe I should change my wording):

Ugh.

Please…no…at some point you have to stop.

71

不不不你最酷。

72

不明白就算了⋯⋯

73

真正生活在 Emacs 里面的, 而不仅仅是编程的, 撇开各种浮华的东西(就是那些你第一眼看着很酷, 其实新鲜过就很少用的功能), Emacser 只需要三个部分:

  1. 高性能的text programming world来处理快速编程, 保持全键盘操作, 最大程度减少鼠标操作对编程心流的打断
  2. 智能的语法补全,就像 VS 那样, 这方面要等待 LSP 的成熟
  3. 各种辅助GUI工具, 比如浏览器, PDF阅读器, org/markdown实时预览等, 减少切出 Emacs 的概率, 最大程度利用 Emacs 高效的窗口管理, 以及一体化协作

上面这三点就是每一个长期生活在 Emacs 中每个人最朴素的三种需求.

然后大家理性分析一下:

  1. 文本处理, 不论你用的 X11, Qt/Gtk, Cocoa, 还是 WebKit 技术, 说白了, 最后都还要回归文本的字符串处理, 不会因为使用了 WebKit/JS 技术, 字符处理这一块 VS Code 就要做的更好, JS/CSS 对于字符的渲染更好, 但并不意味着现有的IDE对字符的操作理解和积累更深入, 大家都用了这么长时间, 大家见过哪个IDE社区的开发者像Emacser这样几乎打磨每一个键盘操作细节? 能一步操作的决不让你做两步操作. 所以在文本这块操作方面, Emacs是做的最好的,别的IDE不管用什么技术, 都很难追上Emacs几十年在文本处理方面的长期积累.
  2. 智能补全这一块, 从我最开始写 auto-complete 开始, 包括同期的 company 发展, 一直都是Emacs软肋, 这方面不用质疑, IDE要甩Emacs很多很多条街, 究其根本在于智能补全后端和前端细节需要极高水平的黑客去开发, Emacs社区方面很难在人力资源上做那么强的投入, 特别是那么多编程语言. 大家还记得CEDET吗? 这个几乎是过去几十年, 唯一在以一己之力开发补全后端的黑客, 但是工作量太大, 没有任何一个黑客可以开发针对所有编程语言的智能补全后端, 所以LSP真的是很好的方向, 几个黑客聚焦一个编程语言, 通过框架的方式来增强智能补全这一块, 不论是人力资源协作还是持续发展方面都非常有潜力.
  3. GUI辅助工具, 大家要有一个理性的认识, Emacs社区是不可能为了GUI辅助工具的发展, 用新的编程语言或者新的图形库来重新开发Emacs的, 因为这样就意味着第一点文本处理的几十年积累要彻底弄得不兼容, 如果没有Emacs几十年文本处理的内涵, 而仅仅是GUI强大, 比如可以上网和看PDF的图形框架, 你真的会用吗? 那还是 Emacs 吗? Emacs 发展这几十年, 那么多替换 Emacs 的项目有几个成功了? 因为开发一个像Emacs这样生态的巨型软件已经超出一个黑客一生的精力, 没有人能够对抗几百名开发者. 大家也许会说, 你看 VS Code 不是发展的挺好的吗? 是的, 我本人也非常喜欢 VS Code, 确实做得不错, 高水平高质量的作品, 但是大家不要忘记了, 这个世界上只有 Emacs和VI 始终是保持全键盘操作开发所有插件的, 生为 Emacser 这么多年, 早已无法忍受鼠标操作, 哪怕你只要我点一下鼠标, 都会觉得效率在点鼠标那一刻降低1000倍, 长期这样混用鼠标和键盘, 会极大打断专注编程心流, 这一点非常重要, 我认为Emacs/VI的用户编程水平这么高最关键的一点就是对编程心流绝不打断的设计理念.

分析了那么多, 想和大家说的, 考虑问题要根据历史, 根据社区资源发展, 根据全方位理性去考虑:

  1. 继续用 Emacs 的文本编程环境, 就单单编程的专注环境上来说, IDE那种针对鼠标的设计理念没法和 Emacs 比
  2. 等待 LSP 的成熟, 微软也在开放, 世界也在开放, 真的期待全世界编辑器和IDE共用智能补全后端的时代, 道不同但相互支持
  3. GUI的辅助工具只有类似 EAF这一条路, 这条是唯一可以保证不颠覆Emacs现有生态情况下, 扩展 Emacs GUI 能力的正确方法.

发表一下个人观点:

  1. 继续用Emacs, 然后用Emacs自己的方式扩展Emacs, 只要用心方法总会有方法的.
  2. 如果实在等不及LSP的发展又严重依赖智能补全, 用 VS Code 或其他IDE产品, 挺好的, 何必自己边折腾Emacs边骂Emacs呢? 不划算
  3. 如果对智能补全依赖可有可无, 裸敲都可以敲出牛逼代码的, 继续用Emacs吧, 不要想着Emacs用新的图形库重写Emacs的, 不可能.

最后, 真的期待GUI发展的同学, 快点学习 PyQt5 然后给 EAF 做贡献吧, 既然那么期待GUI的发展,为啥不从现在就开始做了?

15 个赞
74

cecdt我觉得是因为速度慢 而不是难度大

实时预览应该只是GUI的一部分

从预览的内容修改源码，预览的增量查看才是真正的GUI

75

牛逼轰轰的领导语气是吧? 哈哈

76

No. I never label leaders or teachers with bigotry, ignorant, whiny, or cool.

77

Jeff Atwood doesn’t need another stack exchanges, maybe that’s why he develops Discourse. Anyway, be nice/kind is a must on all forums.

78

不是GUI辅助工具, 而是类似以前firefox里的emacs插件或vim插件, 以emacs的方式操作浏览器, 上网, 并不离开键盘, 你理解错了.

不变的是操作方式, 而不是内容, 能用同样的操作方式操作更高级, 更丰富的内容, 是很多emacser的追求.

就像emacs从终端发展到GUI(支持gtk, win32 GUI, NS), 后者对前者也是巨大的资源消耗(资源消耗增加很多倍), 软件就是这样一代一代进化的. 现在即使不用electron, 也会逐步增加类似功能, 朝着electron方向发展. emacs现在是维护人手太少了, 可能只能这样一点一点增加, 如果人手足够, 直接基于webkit还是很有可能的, 毕竟xwidget功能已经集成进来了.

你一直给我的感觉好像是受限于一些经历, 认为有些东西很难搞定, 或者工程量太大不敢去想. 受限于国内黑客水平, 我们想象力还不够丰富, 然而国外的黑客能力确实会超出我们意外.

1 个赞
79

对方言论里骂人的话都被你点赞了

80

个人观点，希望大家考虑的更长远。

如果重做一个，那就做的像vs vode那样的吧，我只是想说明emacs社区现状不可能重写的，和能以及想象力无关，而是现有生态兼容性要考虑。

国内开发者没有想象力和能力问题，请不要误解我的意思。

2 个赞
81

不是重写, 直接用eletron也不是我想象的, 而是深度定制, 将js引擎替换成elisp, 更换成webkit加elisp的架构, 这样底层图形部分用现成的, 上层软件生态不影响

82

有个IDE叫 Atom

83

如果你对图形开发了解的话，你就知道你这种想法几乎跟重写是差不多的。

84

目前图形部分, c和lisp的交互主要是text和text property还有overlay的设置和获取, c部分相当于服务, lisp相当于客户端, 这两部分耦合不是很紧密, 最主要的渲染部分在c里面(大名鼎鼎的xdisp.c文件), 渲染过程中的内部数据都没有暴露给lisp, 这个替换工作量还可以.

而且c里面的渲染引擎很长时间一直没找到人维护. 也许用webkit之后就不需要维护了, 只需要维护eilsp和webkit之间的一层适配即可.

不是这方面的专家, 这方面的开发稍微涉及过一点.