什么意思我默认的配置里没有这一项 ，我确定，其他全是默认变量值，关键是我 -Q 后依然啊，所以应该不是这个问题。
然后他们觉得：反正不是我的问题 不管了
Emacs 开发者有挺多用 fcitx 的啊，倒不会不管。
这倒是，我已经发了。不过我觉得他们应该不会管的，我之前找到的和这个问题一样的maillist几年了都不管，所以不报希望，倒是我想给fcitx发个bug，估计他们会管。
测了一下 mark-whole-buffer, 
确实没有性能问题（不知这个方法是否准确）：
(defun my/mark-whole-buffer (fn)
(interactive)
(let (begin-time (current-time))
(funcall fn)
(message "completed in %fs" (- (float-time (current-time)) (float-time begin-time)))))
(advice-add 'mark-whole-buffer :around 'my/mark-whole-buffer)
我之所以感觉到慢，原因果然还是 linum-mode 和折叠。用一个 900 行的源代码文件做测试，在同时开启行号 & 折叠的情况下，长按向下键：
18 public function func0()
19 {...}
21
22 public function func1()
23 {...}
147
光标移动轨迹不连贯，卡顿、大幅跳跃，即便光标所在的行不存在折叠。关闭行号／折叠其中一项就正常。
你的问题描述有点玄乎，感觉大概率要被邮件组忽略的。
你们厉害,直接提bug了
哈哈，你这想法太有意思了。不过emacs开发人手很短缺啊，还是节省一点人家的时间吧。
这位回复的是emacs开发主力啊，资源宝贵
我 喵喵 你话可是要按照基本法的啊 要负责的啊 真的？？？？
真的yeah 还是emacsfordos的开发者还有编写elisp手册 我去 哎呀 好气啊
magit的buffer里移动光标会触发很多magit的动作，比如当前section的检测和高亮，牵涉到你说的不可见文本的处理。
楼主从事什么工作的，居然需要 emacs？
我找到最终bug了，是因为fcitx默认开启一个叫做剪贴板支持的插件，当我cut大文件的时候，它默认读取监视剪贴板，由于体积问题，它卡死了连带emacs不能动，因为光标的主动权是在fcitx手中的，它卡死了，光标卡死 是必须的。
2 个赞
业余爱好而已
我之前就怀疑你在全选的时候操作剪切板了：
所以跟 Emacs 压根就没关系咯。
不是我开启它，是它安装后默认启用这个插件的。
你的意思是不是我在全选后用 ^+; 来查看剪贴板？ no
我的意思是只要启用这个插件就会有这个问题。
也许，但是在其他软件就没有这个问题，我觉得可能是有连带因素在里面的，还记得以前emacs里都不能用fcitx输入中文，arch-linux wiki上有解决办法是通过更改emacs的local来做的，所以我觉得两者有冲突。
最近我在使用fcitx-sogou在emacs-buffer里乱打字 fcitx又死了，但是在终端里进行同样的操作就没事，所以我严重怀疑他俩有仇，开玩笑。
我怀疑是sogou的云匹配，还好我用rime本地的。