正在下载镜像 明天晚上装 幸好我为我的操作环境写了一键脚本 只要换dnf 到 pacman就好了 我估计是wayland的锅，arch可以自定义 我就老实gnome2 了
我还有一台 06 年的 Dell，系统 Windows Vista，屏幕已经发黄了，明天搬出来试试😅
1 个赞
@Angelaneia 不太清楚剪切操作和 Wayland 有啥关系。。。
你可以用其他编辑器打开文件，确认和系统组件有关再说，省得瞎折腾一气。
@et2010 spacemacs 0.300 正式版啥时候能发？
我好久不折腾 emacs 了。现在就等新版本发布再试试，看能否对 emacs 重拾兴趣 ⚆_⚆
1 个赞
我最近在忙别的，没有一直关注 spacemacs 的进展了。可能 spacemacs 的开发者也是各自忙别的去了吧，PR又开始堆积了。。。
先用 develop 版吧，我现在稳定在 develop 的一个位置，目前还没有遇到让我非更新不可的 bug。主要是我也不更新 emacs 插件了，melpa 上已经有 70 多个插件处于过时状态了。不过一切都好，稳定压倒一切 
等到有时间了再重新回到滚动更新的生活。。。现在如果更新插件的话，不知道会有什么噩梦在等着我
GTK 会给 Emacs 带来额外的 bug。建议你自己编译一份以 athena 为 GUI Tool Kit 的 Emacs试试，虽然丑了点但是比较稳。而且关了工具条和滚动条就没区别了。
同上，我也是mac平台，用的是mac port emacs版本，没有出现这样的情况。
或许跟 Emacs 有多少关系（或者说 Emacs 不太像是这个问题的根源），只要你不做一些复杂的操作（比如统计选中区域的字数之类），选中 1 万行和 1 百行真有什么区别吗？（不都是设置好 Mark 和 Point，然后高亮下屏幕上可见的几十行么？）
你应该试试 emacs -Q 看下能否重现，如果能的话，报告一个 Bug。
一直不敢也没兴趣试 spacemacs， 感觉用它就是天天拿板砖呼脸
没有那么夸张，只要不是滚动更新，稳定的很。我现在基本上只需要修改我自己写的包，然后调整自己的工作流就行了，根本不需要操心 spacemacs 了。
其实用开放的心态去尝试一下新事物也没什么不好
我还是中意自己的配置，虽然简单，但是好控制，代码熟悉，想改就改
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，看看能不能解决。
各位大佬，谢谢你们帮我重复实验，但是我还是不明白一个输入法框架会导致这个问题 ？
让我可悲的是我 前天就和gnu.emacs的bug组提交问题了，他们先是让我把问题讲清楚，然后我原样把这里的描述copy给他们了，然后居然他们直接提交了，这，我该怎么回复他们，让他们撤掉 ，毕竟这不是emacs的锅，但是话说回来，vim就没有这个问题，也是用的fcitx。
邮件内容：
不着急，说不定他们最后还真能找出来个 bug
666 
我总不能不回吧
你是不是开启了选中即复制？
你直接如实写 开启 fcitx 输入法时可以复现，由他们研究到底是哪里出的问题。