如题。有时候分两个窗口看同一个文件，看右边的写左边的。有时按出一个命令以后，光标就会自动跳到和右边窗口相同的位置。
我在 GNU/Linux 上，Emacs 27.2 和 28 都有这个问题。
已经发现的诱因包括：
- 高频率更改 modeline（受影响的包：mode-line-bell)
- 高频率更改 header line（手动用 timer 更改可模拟）
- 高频率更改 minibuffer（受影响的包：mini-modeline，见这个 issue）
- 操作 buffer 内的 overlay，特别是两边都可见这个 overlay 时（受影响的包：company，paren（提供 show-paren-mode））
感觉这个配置得越多越容易出现，在 $ emacs -Q 里不好复现，不过我已找到大概率复现的方法，并向 Emacs 报了 bug：#44448 - 27.1; Strange inteference between timer, modeline/header-line and buffer position in window - GNU bug report logs
这里是我在报告里附上的录屏。我在 post-command-hook 里运行 show-paren-function，这样可以增加复现的几率。注意到成对的括号是分别在两个窗口高亮的。按住 ctrl 以后同时敲几次 f+g+b（模拟快速发送 C-f、C-b、C-g）以后，左边窗口的光标跳到了右边的位置。
其实发这个帖子只是想问下各位真的没有碰到类似问题吗 
我已经被折磨两三年了，去年我认识到用 timer 刷新 modeline 或 minibuffer 会导致问题以后，慢慢地把相关的包都去了，modeline 也自己写了，甚至其他一些用 timer 的包也干掉了。最近我才发现 overlay 也会导致问题，把 company 和 show-paren-mode 都干掉就完全好了，可这样的话编程效率要降好多 其他 company 用户没有碰到这个问题吗？
想到之前遇到的一个类似 bug，像是和并发有关。
再多说一句
Less is more
在 EmacsTalk 还没发布的一期节目里，那个嘉宾尽量用裸的 Emacs，保证开发环境的简洁。我最近也一直再给自己的配置减负，轻易不再把一些“华丽”的包加到自己的配置中。
我感觉 Emacs 用户可能可以分成三类
一类是「今朝有酒今朝醉」的，看到什么酷炫的的包都弄到配置里，爽了再说。
一类是「人无远虑必有近忧」的，你说的这种是一种，还有一些人只用终端上的 Emacs，还有一些人觉得某些包有被放弃维护的风险就不用了。我觉得这种在 Vim 党里有很多。
一类是「我的 Emacs 我做主」的，追求自己设计自己的编辑体验。包不在多，但配置里有好多 advice，改造不成我想要的样子就浑身难受，一言不合就造轮子。
我自认属于最后一种，感觉懒猫也应该算最后一种 
1 个赞
我毫无疑问是第二种了，没有那么大的折腾心了，感觉可以采访一下你们，看看是如何保持旺盛精力的。
kinono
10
其实刚收到邀请了，但是拒绝了
是因为某些个人原因，我其实还是很想掺和的 希望今后能有机会
但是你对我好奇的话可以文字采访我呀
是我，不过不大折腾了，只添加特别对生产力有提升的包 （但我配置的 纯洁性 还是要保证的，不然浑身难受
我把Emacs当作自己的爱好，没事的时候玩一下，累的时候玩一下，慢慢的很多事情都会过去的。
1 个赞
经常这样编辑, 从来没遇到过, 不过我的版本是26
1 个赞
kinono
17
跟着 Emacs 维护者折腾了几天，现在这个 bug 应该是修好了，至少我玩了一晚上没再遇到过。有相同问题的可以编译一下最新版试试。
原因是 redisplay_window 另一个窗口的时候，buffer 的光标会临时移到 window-point。此时如果被 C-g 打断，buffer 的光标位置就不能恢复，看上去就像是跳过去了。
解法就是把可以跳出的地方都用 inhibit-quit 包起来，我发现了五六个这样的地方
没遇到过（也从来没注意到）这个现象。不过按照楼主说的“在 post-command-hook 里运行 show-paren-function”，的确是有一定概率重现：
- 全配置下
(add-hook 'post-command-hook #'show-paren-function)。
- 打开一个超过 1 屏的文件。
C-x 3 左右分屏。- 左边移动到末尾（右边不动）。
- 重复交替按
C-p 和 C-g。
我是「只用终端上的 Emacs」，但不会「觉得某些包有被放弃维护的风险就不用了」。
我感觉不只是「人无远虑必有近忧」，而是忧心世界末日徒手打僵尸的那种焦虑，总觉得有一天会处于极端环境。
我用了几个已经停止维护的包，除非我打算接手它，否则都是 advice 而不直接修改（尽管直接修改更简单），以保持它最后公开发表时的样貌，感觉私自在它内部修改是一种破坏，这也是一种焦虑。
1 个赞
