看起来不像是同一个问题
把 66% 展开呀，不然怎么知道哪里有问题。
最好卡久一点再出报告。
emacs -q markdown-mode.el ，会有：
但是自己直接打开文件，使用 mark-whole-buffer,其实并没有这个问题。
终端下是几乎是不卡的
@kekeimiku @org 自己编译试试看，不要用软件包管理器安装，它们有可能会打补丁或者植入一些额外的包。
又或者打包的环境跟你现在系统存在差异，导致莫名奇妙的问题。我就遇到因为打包平台 SDK 导致 Emacs 28 在我电脑上必崩溃的问题：28.1 不稳定？我刚发生闪退 - #5，来自 twlz0ne
我可以复现，环境和楼主的一样。只要打开一个大文件（我试了 org.el），求值
(progn (set-marker (mark-marker) (point-max)) (setq mark-active t))
这个问题不仅现有版本的emacs，老版本的emacs 同样。 其实 mark-whole-buffer 还会造成更多余下操作卡死 比如：
- 对有 babel block 的 org 文件
C-x h然后M-q然后 emacs 卡死 直到 C-g N 次 （可能恢复，也可能一直 hang）。 - 对 已经 mark 的大 size （可能几兆 关键是要有上万行）的 buffer 进行
delete-forward-char。直接卡死（看机率 C-g 能恢复）。
macos arm-64 emacs-plus native-comp C-h f org-mode 然后打开 org.el，然后执行mark-whole-buffer 毫无卡顿
今年写插件的性能实测， Elisp的性能排序应该这样排：
- GC是Elisp最影响性能的地方， 这也是 blink-search 比 ivy 快的原因， ivy 已经做了渲染优化， 但是遇到超大文件数的时候会触发 GC, 即使 99% 的数据并没有渲染
- Elisp语言的执行性能
- 多线程
我写 lsp-bridge 的时候就一直在思考这三个问题， 多线程基本上无解。
但是前面两个问题完全是可以解决的：
- GC的问题大概率是Emacs诞生的那个时代内存很小， 它默认的策略导致GC太敏感了， 这样一旦遇到超大数据 （比如 rg 或者 lsp) 的时候， GC才是卡顿的罪魁祸首
- Elisp语言的执行性能完全可以引入JIT的手段， 可以逻辑提升代码的性能， 同时也不会带来兼容性的问题
分享一下我的测试结论， 但是我最近越来越忙了， 没有时间对GC和JIT动手术了。
2 个赞
我测试了windows版本的，也没啥问题，linux下的无配置的会有问题，带配置的就没问题，一会真得二分大法看看哪里的配置无意间解决了这个问题。
1 个赞
虽然我找不到原因，但是我找到了解决的方式，我自己的配置文件里 early-init.el 文件里有 这么一条：
(setq select-active-regions 'only )
1 个赞
设置了这个C-x h真的不卡了
(setq select-active-regions 'only)
但是 M-w 开始卡住了…
M-w 卡有可能是 kill-ring 爆了。
临时解决方案，M-w和C-x h 不会卡了：
(setq select-active-regions 'only)
(setq x-select-enable-clipboard nil)
不过我的 yank-pop 又开始卡了…
能不能用 Docker 配一个一样的环境？如果 Docker 里面可以重现，就没有异议了。
不会用 docker 
king 存取的不光是文本，还包括所有的 text properties，剪/贴整个 buffer 信息量巨大，所以 kill-ring-save (M-w) 和 yank (C-y) 卡顿是同一个问题。
我真怀疑你这个发行版的 Emacs 打包是不是有问题，是不是打了补丁，或者预设了某些参数，比如调整了 GC 阈值。
复制粘贴这个问题，我也能复现，不过我自己用wayland,参考了 Wayland clipboard 这个配置，所以没有卡顿，你如果不是用wayland,可以试试它提到的 simpleclip，这个我就不测试了。另外，如果你用meow,可以试试meow自带的复制粘贴，我也没有卡顿。
那就是系统的 clipboard 有问题了，建议题主去 distro 的论论板问问有无能复现的，用的是啥 Window environment.