linux gnome 下 全选整个大于1万行的buffer 卡死

正在下载镜像 明天晚上装 幸好我为我的操作环境写了一键脚本 只要换dnf 到 pacman就好了 我估计是wayland的锅,arch可以自定义 我就老实gnome2 了

:tada:

我还有一台 06 年的 Dell,系统 Windows Vista,屏幕已经发黄了,明天搬出来试试😅

1 个赞

@Angelaneia 不太清楚剪切操作和 Wayland 有啥关系。。。

你可以用其他编辑器打开文件,确认和系统组件有关再说,省得瞎折腾一气。

@et2010 spacemacs 0.300 正式版啥时候能发?

我好久不折腾 emacs 了。现在就等新版本发布再试试,看能否对 emacs 重拾兴趣 ⚆_⚆

1 个赞

我最近在忙别的,没有一直关注 spacemacs 的进展了。可能 spacemacs 的开发者也是各自忙别的去了吧,PR又开始堆积了。。。

先用 develop 版吧,我现在稳定在 develop 的一个位置,目前还没有遇到让我非更新不可的 bug。主要是我也不更新 emacs 插件了,melpa 上已经有 70 多个插件处于过时状态了。不过一切都好,稳定压倒一切 :rofl:

等到有时间了再重新回到滚动更新的生活。。。现在如果更新插件的话,不知道会有什么噩梦在等着我 :rofl:

GTK 会给 Emacs 带来额外的 bug。建议你自己编译一份以 athena 为 GUI Tool Kit 的 Emacs试试,虽然丑了点但是比较稳。而且关了工具条和滚动条就没区别了。

同上,我也是mac平台,用的是mac port emacs版本,没有出现这样的情况。

或许跟 Emacs 有多少关系(或者说 Emacs 不太像是这个问题的根源),只要你不做一些复杂的操作(比如统计选中区域的字数之类),选中 1 万行和 1 百行真有什么区别吗?(不都是设置好 Mark 和 Point,然后高亮下屏幕上可见的几十行么?)

你应该试试 emacs -Q 看下能否重现,如果能的话,报告一个 Bug。

一直不敢也没兴趣试 spacemacs, 感觉用它就是天天拿板砖呼脸

没有那么夸张,只要不是滚动更新,稳定的很。我现在基本上只需要修改我自己写的包,然后调整自己的工作流就行了,根本不需要操心 spacemacs 了。

其实用开放的心态去尝试一下新事物也没什么不好 :rofl:

我还是中意自己的配置,虽然简单,但是好控制,代码熟悉,想改就改

debian9 gnome 没有一点问题啊,剪切复制粘帖立即完成。 i5 双核四线程

据我观察(也许有误),似乎不仅仅是 Mark 屏幕可见的几十行,而是会一直 Forward 到文末,并且会对不可见区域的文本进行“渲染”,所以在 org-mode 全选比在其他 mode 会慢一点。

另外一个例子就是 magit,当 commit 历史达到相当数量的时候,就变得非常慢了,而其他 git 客户端不存在这个问题。按理说屏幕可见的也只有几十行,把整个 commit 历史读取到内存也不耗费多少时间,问题可能就出在 Emacs 会 Forward 并处理所有不可见的行了。

我依然不觉得「选中」这个操作是个耗时的操作,C-x h (mark-whole-buffer) 应该跟 M-> (end-of-buffer) 等的速度差不多,但是我的猜测正确与否并不重要,假如 OP 能够用 emacs -Q 重现他的问题,他应该向 Emacs 报告一个 Bug。

至于 Magit 的例子,我也不怎么清楚,但我觉得历史太多,比如 10 万个 Commit 之多时,第一次读取应该会很慢(如果不是异步的话,应该会很「卡」),因为一行一行解析(说不定用的正则表达式)、渲染、插入很慢也情有可原,而专门的 Git 客户端应该能直接读取 Git 的数据,不必调用 git 解析其结果,可能就相对会快很多。不过这个例子跟「选中」这个操作没关系,我不觉得在一个 Magit Log Buffer 中,即便它的内容很多,C-x h (mark-whole-buffer) 会卡,或者说比其它的操作,如 C-n (next-line),慢到哪里去。

在 Gentoo Linux 上的 X Window 用给出的测试文件和文件Vanilla Emacs 25.3 Athena tool kit 没有复现。实际上不管是全选复制粘贴和翻页都没有发生任何卡顿。用的是我的 MacbookPro 2012年中低配。

目测估计是 Wayland 的锅。

趁着中午没人,我重新装了linux发行版(fedora27---->arch)为了尝试一下最后的希望(在emacs-china上听说虽然 大多数人使用mac来使用emacs,但是很多用linux的人使用emacs没有这个问题,他们使用的 archlinux)。

起初刚刚安装玩全新的系统我就使用了一下emacs,结果是真的没有这个问题了。我很高兴,并认 为这就是发行版本的问题。

可是我并没有想到事情的发展会这么戏剧性,随着那一阵高兴我很快的配置完了我所需要的操作环 境,并且用了一会儿并没有再实验emacs的这个bug。

过了一会当我有再次尝试的时候,发现问题又出现了,这是为什么?

我通过把我的记忆定位到没问题时候的系统配置和现在对比,发现了一个自己都不敢认为的因素, 这居然是fcitx的锅(使用的后端是rime)。卸载后,bug没有复现,改用ibus-rime了,但是担心ibus卡的问题,但是没有办法。估计是机器配置的问题了,升级吧,有空把这个bug提交给fcitx,看看能不能解决。

各位大佬,谢谢你们帮我重复实验,但是我还是不明白一个输入法框架会导致这个问题 ?:thinking:

让我可悲的是我 前天就和gnu.emacs的bug组提交问题了,他们先是让我把问题讲清楚,然后我原样把这里的描述copy给他们了,然后居然他们直接提交了,这,我该怎么回复他们,让他们撤掉 ,毕竟这不是emacs的锅,但是话说回来,vim就没有这个问题,也是用的fcitx。

邮件内容:

不着急,说不定他们最后还真能找出来个 bug

666 :joy: 我总不能不回吧

你是不是开启了选中即复制?

你直接如实写 开启 fcitx 输入法时可以复现,由他们研究到底是哪里出的问题。