建议搜索一下,肯定是有区别的
blink-search已经是针对界面做渲染处理的,效果是很好,但是我要说的是,仅限于普通的列表渲染实现复杂度还行。
但是对于上下文很长的情况,像emacs这种编辑器,还有很多视窗外的对象需要处理,编辑器级别做可视化坐标渲染转化工作量会大很多。
我之所以回复这么多就是如果你有什么想法你自己做吧,现在的问题不是能不能做的问题。而是做之前你和不懂的人沟通,浪费彼此的时间。
因为你和没有做过图形编程的人沟通,你并不会说服他们,他们反而拿着局部的知识和你掰扯对和错,你要从普及多线程图形编程开始说,累不累啊?
话说现在mps有望解决gc导致卡顿的问题吧
没用过哇, 期待。
有编译好的mps版本,猫哥品鉴下呢
主要是 EAF + lsp-bridge + blink-search 这三个工具已经卸掉我99%的GC了, 所以我超级流畅哇, 哈哈哈哈。
@manateelazycat 看了大佬的帖子 New Emacs 构想
提一下这篇博客 Emacs GUI library · Andrey Listopadov
其中提到 https://gtoolkit.com
阅读了这篇博客之后的一个思考就是:
Emacs 用户真正需要的一定是在 Emacs 的纯文本界面中做一切事情吗?
还是一系列围绕着软件开发所需要的,所有可互相感知的功能组件。尤其是在图形界面能提供越来越多直观帮助的今天。
我打算有空深度尝试一下 GToolkit
我理想中的开发环境:一个 GUI 界面管理 Workspace,在 Workspace 里开启各种各样的 GUI Widgets 之类的东西,比如 VCS View 使用像 Magit 这样的工具, Edit View 我可以选用 helix,还可能有 Test View、 Run View,通过统一管理的键绑定在这些功能组件间自如切换。
我以前读过, 不要有洁癖, 现在EAF就已经实现了外部GUI和Emacs无缝融合(mac用户支持不了)。
如果有洁癖, 就是New Emacs (NeoVim)那样搞, 但是工作量巨大, 完全可行, 头发要掉一半。
如果没人做, 我觉得大家就不要讨论了吧, 纯粹浪费时间。
新的 emacs 版本下,mac 上配置 eaf 也达到可用水平,尽管 eaf 的界面有时会不跟着 emasc 的窗口走,但总算可用
是嘛, 大佬发一张截图看看?
可用了么?怎么配置的呀
有点尴尬…
之前用的是 30.91,当时是可以用的,看 pdf,上网,还有 file-manager 和 pyqt-terminal 都没啥问题。但昨天升级了 31,是 emacs-plus@31 这个发行版,然后发现出问题了:
我升级 emacs-plus@31 的目的是能够使用中英混输的 patch。
总之,在前天,我还很愉快地用 file-manager 来找文件,看了一会儿 pdf。
emacs-plus@30,没特别配置, 就是官方 Readme 的参考配置。但我现在 emacs-plus@31 有问题,请参考我上一条回给懒猫大佬的回复。
看看是不是依赖没装
可以切到eaf的buffer,会有报错提示
我在 emacs 下运行 eaf-install-and-update 和在终端里运行 chmod +x ./install-eaf.py ./install-eaf.py,反馈如下消息,应该是依赖已经装了:
[EAF] Installing core dependencies
[EAF] Running pip3 install --user --break-system-packages -U epc sexpdata==1.0.0 tld lxml mac-app-frontmost PyQt6==6.5.0 PyQt6-Qt6==6.5.0 PyQt6-sip PyQt6-WebEngine==6.5.0 PyQt6-WebEngine-Qt6==6.5.0 @ /Users/chenyibin/.emacs.d/lisp/eaf
Requirement already satisfied: epc in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (0.0.5)
Requirement already satisfied: sexpdata==1.0.0 in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (1.0.0)
Requirement already satisfied: tld in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (0.13)
Requirement already satisfied: lxml in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (5.3.0)
Requirement already satisfied: mac-app-frontmost in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (2020.12.3)
Requirement already satisfied: PyQt6==6.5.0 in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (6.5.0)
Requirement already satisfied: PyQt6-Qt6==6.5.0 in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (6.5.0)
Requirement already satisfied: PyQt6-sip in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (13.8.0)
Requirement already satisfied: PyQt6-WebEngine==6.5.0 in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (6.5.0)
Requirement already satisfied: PyQt6-WebEngine-Qt6==6.5.0 in /Users/chenyibin/Library/Python/3.13/lib/python/site-packages (6.5.0)
你这这是安装了核心, 应用的依赖没有安装吧, 看看 *eaf*
啥内容?
应用依赖太长就不发上来了,都显示 Already up to date.
*eaf*
buffer 啥内容? 但是我觉得不应该在这个帖子下歪楼, 你要不是 python 依赖没有装, 要不就是 npm install ; npm run build
没有执行。
非常赞同。
Doom 的做法实际有点自欺欺人。虽然启动时间数字很好看,却并没有真正解决问题,而是把卡顿碎片化了,导致用户在启动之后的很长时间内,不断遭遇短暂的卡顿。
归根到底还是 Emacs 本身的问题,不能把锅扣给某个配置和包。即使快如 lsp-bridge,仍受累于 Emacs 简单粗暴的绘图机制,丝滑度(不是速度)比起 VSCode 还是略逊一点点,时不时能看到画面闪烁。
想要流畅必须优先响应用户输入,即使数据没准备好,也不该阻断用户操作。用户按下按键,最重要的是先把按键结果体现在屏幕上,不管是输入字符还是移动光标,补全项有没有准备好、画面有没有渲染完都在其次。