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


#106

我的eaf已经不会让这些来回切换了


#107

你这是什么操作需要来回切换才能完成…

就算是集合到Emacs你也得切换buffer吧,跟切换应用差不了太多。


#108

请问 EAF 可以用在文本编辑当中吗?在我看来它只是提供功能各异的buffer,并没有对编辑器有直接的帮助吧,类似 child-frame 或者 lsp-ui 这种文本 overlay 。

另外,EAF 能否和 emacs 的变量进行交互吗?比如使用或修改 emacs 中的背景色等等。

个人认为,加强 GUI 是必然趋势,但不一定要靠 Web


#109

第一点其实很容易做,一个Qt无边框窗口的GUI性能和界面细节就可以秒杀现在Emacs所有的弹出插件, 并完美解决CJK没法对齐导致 frame 右边锯齿的问题, 但是不是eaf这个项目的目标

第二点已经具备这样的能力了elisp和python互通调用


#110

所以 EAF 还是提供功能各异的 buffer 咯?其实我更在意纯编辑 buffer 上的实现,用 PyQt 给 buffer 上贴一层透明的膜听起来也是蛮暴力的:joy:


#111

所以这就是Emacs的现状, OldSchool这一派的就喜欢framebuffer, 终端和文本世界, 大家都不喜欢让Emacs默认就是基于Gtk+/Qt这类现代图形库的基础之上来构建.

这也是EAF的目标,在最大程度扩展Emacs GUI能力的前提下, 保证Emacs Text World不进行任何修改,保持原样即可.

EAF 可以说最暴力的贴膜插件, 你说的一点都没错, 虽然我可以用Qt开发一个编辑器贴上去, 但是在Emacs面前就不开发编辑器插件了, 自讨苦吃.

你说的, 像 Auto-Complete和Company那样在Emacs现有的 text buffer 之上扩展Emacs是很容易做到的, 写一个独占式的Qt窗口贴上去, 然后根据 point 的位置,实时更新Qt窗口左上角的坐标即可, 单这种独占式的窗口和EAF这种View/Buffer框架设计目标不一致, 很容易实现, 等我哪天有心情了, 就写一个出来.


#112

目前工作限制,linux只能用centos,安装pyqt5需要手动编译一些东西,还没用上


#113

可能工作内容太杂了吧,切换确实很频繁,浏览器多数是查文档和使用一些在线服务,终端更频繁,后台开发,命令行用的多,连接的服务器也多。 emacs里面helm或ivy,这种切换没问题,我的emacs一般多窗口,buffer切换频率也很高。操作多了有点条件反射,切换不同app也会不小心用emacs的快捷键


#115

哪是人人都能做到说干就干呀,技术是每个人地瓶颈啊。


#116

个人觉得是不是PyQt5太庞大了一点,光库就有150+MB了,上次想写个小工具10.6KB然后用pyinstaller打包就有50+MB了,难道是姿势不对?想请教一下。


#117

就是这位作家:


#118

和你聊这么多的是深度操作系统的大神:sweat_smile:


#119

准确的说应该是 前深度科技CTO :rofl:


#120

听说过但是没用过深度的系统(linux), 有同事用过, 说太卡了, 很快就卸载了, 了解不多.


#121

谁是,大神在哪里,我要磕头


#122

关于webkit内存占用太多的问题, 可能为了空间换时间或者其他用途, 但是, 回忆以下十年前的浏览器, firefox 3.x的年代, opera, 都很省内存啊, 一般占用几十或几百兆内存, 渲染效果已经非常好, 性能也可以, emacs能用这些老的渲染代码也完全够用, 可以支持上真正的图文排版


#123

lazycat, 这个论坛里最热的几个贴子都是他发的,写的好几个package我正在用。


#124

不卡, 就是比较吃硬件。 但是非常好用,而且现在深度系统和深度桌面(dde) 是可以拆开的 我这几年都用arch+dde 或者manjaro+dde


#125

懒猫不想在 emacs 社区讨论深度的事情,大家还是尊重他吧。


#126

webkit和浏览器渲染引擎是本主题相关, 与深度系统无关