据说是性能变好了，还有其他的吗？
就是性能好啊，这点足矣。不过大文件最好关闭行号显示。
一个是C写的底层，一个是纯elisp，性能差别可大了。能用就直接用 display-line-number-mode，不用纠结。
但是听说还不如nlinum？
display-line-number-mode:
- c 实现
- 在
display_line中绘制行号 - 可定制：
linum-mode:
- elisp 实现
- 在
post-command-hook中绘制行号 - 可定制：
刚刚启用 linum-mode，打开 10 多兆大小的文件，感觉不到有什么影响，可能还需要其它因素的配合。
3 个赞
最近重新整理了自己的配置，尽可能少地定制。看这个贴子的时候，我也不确定我到底有没有开启行号。
刚刚确认了下，我发现竟然没有开启行号，看来也没什么影响，我都没有注意到 
不知道你从哪里听说，说性能不可能，可配置性另说。nlium 基于linum，也是elisp实现的啊。
打开大文件，开启语法高亮区别就大了，linum-mode会时不时造成卡顿。当然机器性能好就当没说
2011 年的老电脑。
打开 12.5M 的 csv 文件，高亮不复杂但也有那么一点。打开 1.2M 的 c 文件，高亮 + lsp。
elisp 肯定比 c 慢。但是从 linum 的实现看，它只绘制可见的那几十行的行号，也不至于到卡顿的地步。应该是更多因素的叠加才导致它性能进一步下降。
我感觉比较可疑的就是 post-command-hook。Emacs 没有表示窗口显示内容发生变化的 hook，所以很多函数都放到 post-command-hook 中。会不会因此触发一些不必要的刷新动作？
1 个赞
csv问题不大，我感觉跟语法高亮冲突比较大。例如，大一点的js文件就比较明显。js2-mode 性能可能也有问题，但是关闭linum-mode肉眼可见的提升。还有就是超大文件也有明显卡顿。我想这也是为什么要另起炉灶搞display-line-number 的原因吧。
这里有一些信息和讨论：
View large file more than 300000 lines very slow. · Issue #178 · redguardtoo/emacs.d (github.com)
我用 emacs -Q 和常规配置分别测了一下 7M（12万行）的 js 文件。
emacs -Q 没有迟滞感。常规配置其实也还好，就是刚开始 lsp 启动的时候会把 cpu 占满，等一下就可以正常编辑了，连续快速操作偶尔卡顿。
开启 evil-mode 翻页时发现 linum-update-window 重复执行达 10 次，不开启则只有 2 次。我的电脑每次 linum-update-window 大约是 0.005s，配置多寡没有区别。
各种 hook 叠加起来的消耗不可小觑。我这里 emacs -Q 的 post-command-hook 有 4 个函数。常规配置的 post-command-hook 有 15 个函数。
1 个赞
注意到了linum-mode在帮助文档中显示行号的一个小问题，display-line-numbers-mode没有这个问题。
在Windows上运行emacs 27.2。用emacs –q启动，Ctrl-h i进入帮助，然后运行Alt-x linum-mode
在这个帮助页面行号显示有点问题
Emacs->Commands (4 Keys and Commands)
在本页的最后一行
另外，本页没有第四行，不知是不是被隐藏了。
2 个赞
macOS 上也可以重现，且不止 27.2，而是从 27.1 ~ 29.0 都存在该问题。
但不是每个 info 节点都出问题，且必需遵循特定的步骤才能重现——先打开根节点，再打开子节点：
$ emacs27+ -Q --eval "(add-hook 'Info-mode-hook 'linum-mode)"M-: (info "(emacs)")M-: (info "(emacs) Commands")
虽然以上步骤 3 可以直达 Commands 节点，但是步骤 2 不可省略。
display-line-number-mode 好像没有这个问题，又多了一个理由？
我两者都用。
常规用 display-line-number-mode，narrow 状态下用 linum-mode 加 (setq linum-format "%4d│ ")
