现在emacs-gui有哪些版本，比较有前途的是哪个，还有gnu那边对GUI的规划是什么有谁了解吗。
emacs的前端渲染太差劲了.
1 个赞
会向着 VR 语音交互 等方向发展
屏幕会被会逐渐的取代
2 个赞
图形渲染部分好像是没人维护的状态, 多年前更新过一次, 然后就没人接手了, 没有专门的维护者了, 现在只是小修小补状态. 好像还没看到什么计划, 一直在找维护者, 还没找到, 因为太复杂了吧.
emacs如果能基于electron, 简直是完美了.
1 个赞
所有基于Web开发的大型软件和操作系统都会因为JS的先天缺陷导致严重的,无法补救的内存泄漏.
1 个赞
感觉在每个平台下都做到native且能使用gpu加速才够爽啊hhh （千 秋 大 梦）
2 个赞
@fuxialexander 不要相信Google和那些前端工程师的JS大梦, 99%的前端工程师都没有写过操作系统和本地客户端的代码.
浏览器技术如果不能解决JS的内存泄漏问题, Web为核心的技术永远都不如本地GUI库开发的操作系统和客户端稳定和高性能.
这也是我认为如果一样多的钱, VS Code 不会比Sublime发展的更好.
9 个赞
可惜 McCLIM 的 OpenGL binding 没有什么动静。
玩高科技还是玩Linux吧, Mac上就应用比Linux多一点, 方便一点, 其他没啥优势.
1 个赞
嗯嗯我说的就是sublime的模式 在每个平台下用native的GUI框架开发
sublime 默认是GTK+开发的,应该都可以使用各个平台的加速.
除非是OpenGL渲染,一般2D的只是借助显卡加速通道, 加速没有OpenGL基础的加速明显, 但是 OpenGL 技术开发的图形库遇到 Linux 渣渣显卡驱动都会把一个好的项目玩死的.
1 个赞
js感觉跟lisp差不多啊, 也是一个解释器, 如果js不靠谱, 那lisp也差不多. 如果说因为js开发的应用太复杂会内存泄漏, 那用lisp也一样吧?
另外, 由于开发人力资源丰富, js的效率可能比emacs里的lisp高很多.
内存泄露和是不是解释器没关系，而是web的开发方式一定会内存泄露，因为他们只是内容渲染，并不像客户端那样严格管理对象生命周期。
js写抽象语法树能写的过lisp？
js党就是天天歪歪所有东西都用js写，Google一个广告公司，啥说都信啊，真是的
5 个赞
electron就是native啊, 而且支持gpu加速. 最主要的是支持web页面渲染, 可以显示和编辑word设置pdf级别的丰富格式文档, 这个是sublime之类的远远达不到的.
JS的感觉是用的人巨多，还都特别能折腾，搞得就很热闹。
你真的用 Electron CEF 这些开发过本地客户端吗?
C/C++ 启动用时 50ms , Web框架的应用最少 1000ms ~ 2000ms 一个复杂的GTK+程序,可以控制内存在 10M 以内, Web框架本身都不止50MB, 随便加载一个页面就是几百兆内存.
我开发操作系统十几年了, 用WebKit架构构建过整个操作系统, 玩了3年时间, 最后全部用 C++/Go 替换了所有的Web开发的模块.
Html5/JS 永远都不可能成为任何大型程序和操作系统的开发技术选型, 做点像网易云音乐的东西就可以了. 如果真的那么好, Android, ChromeOS, MacOS, Windows底层为啥都不用 JS 开发? 这些都是开发浏览器引擎的大厂啊.
所以, 凡是认真思考, 虚心学习, 不要人云亦云.
10 个赞
复杂度再高一个层级, Sublime吊打VS Code, VS Code 也就写写前端还可以, 内存泄漏的问题早晚成为 VS Code 的发展瓶颈.
还有 Electron 不是 Native, 就是一个浏览器引擎, 还不如 CEF 性能高, 渲染加速都是浏览器和操作系统做的, 如果同样的硬件显卡和加速资源.
浏览器本身就很重, 是不可能有原生客户端直接绘制性能快的.
2 个赞
讨论electron的好坏暂时没多大意义吧，electron已经在某些场景下很成功了。
目前Emacs未来正在走向哪一步呢？ 大佬们关心GUI么？
这个就是静态语言和动态语言的区别了, 没有最终结论, 焦点不在这里.
先不说语法树这些很少用到的东西. 目前emacs的lisp加底层native模式, 跟electron的底层native加js模式基本一样. 如果emacs继续发展, lisp程序也会复杂, 变得跟js一样, 会遇到同样的问题, 现在emacs省内存大部分是因为两者功能不在一个数量级. 也许emacs可以限制自己不发展得那么高级, 等到有新的技术出现.