Recording My First Experience Contributing Code Upstream to GNU/Emacs
内容提要
作者发现Emacs在打开大量缓冲区时tab-line切换卡顿，通过性能分析定位到tab-line-tabs-fixed-window-buffers函数：其排序过程中调用seq-position导致O(N²)复杂度。作者用哈希表缓存缓冲区索引，以空间换时间消除卡顿，并将补丁提交至bug-gnu-emacs，获维护者认可，代码将随Emacs 31.0.51起收录。这是作者首次贡献GNU/Emacs。
延伸解读
性能瓶颈的根源：O(N²) 复杂度
作者通过性能分析发现，tab-line 卡顿主要源于 tab-line-tabs-fixed-window-buffers 函数中的排序操作。该函数在排序时使用 seq-position 查找缓冲区在旧列表中的位置，而 seq-position 需要线性遍历列表，导致整体时间复杂度达到 O(N²)。当缓冲区数量很大（如 1000+）时，这种平方级增长会显著拖慢切换速度。这提醒我们，在性能敏感的场景中，应警惕嵌套的线性查找。
空间换时间的优化策略
作者将旧缓冲区列表的索引预先存入哈希表，排序时直接从哈希表获取位置，将查找时间从 O(N) 降为 O(1)，从而把整体复杂度降至 O(N log N)。这种以空间换时间的做法在 Emacs Lisp 中常见且有效，尤其适合处理大量数据。补丁被维护者认可并合并，说明该优化不仅解决了实际问题，也符合上游对代码质量的期待。
upstream 贡献的流程与意义
作者将补丁提交至 bug-gnu-emacs 邮件列表，并获得维护者确认，代码将从 Emacs 31.0.51 起收录。这展示了开源贡献的典型路径：发现问题、分析定位、实现修复、提交评审。作为首次贡献，作者不仅解决了自身遇到的性能问题，还让改进惠及所有 Emacs 用户。文中提到 Richard Stallman 的评论虽为误操作，但也侧面反映了社区对补丁的关注。
Q&A
Emacs 打开大量缓冲区后 tab-line 切换卡顿，原因是什么？
性能分析显示瓶颈在 tab-line-tabs-fixed-window-buffers 函数：其排序时用 seq-position 查找缓冲区在旧列表中的位置，当旧列表很大时，seq-position 需要遍历列表，导致排序整体复杂度为 O(N²)，从而引起卡顿。
如何优化 Emacs tab-line 在大量缓冲区时的性能？
作者用哈希表缓存旧缓冲区列表的索引，将 seq-position 的线性查找改为哈希表 O(1) 查找，以空间换时间，消除了排序中的 O(N²) 复杂度，使函数处理任意数量缓冲区都不再明显变慢。
优化后的 tab-line-tabs-fixed-window-buffers 函数具体怎么写的？
改进后的函数先用 make-hash-table 创建哈希表，通过 seq-do-indexed 将旧缓冲区及其索引存入表中，排序时用 gethash 获取索引（找不到则返回 most-positive-fixnum），从而避免 seq-position 的线性搜索。
这个 Emacs 性能补丁被官方接受了吗？会进入哪个版本？
补丁提交到 bug-gnu-emacs 后，上游维护者确认这是正确的修复，代码将从 Emacs 31.0.51 版本开始收录。
作者是如何发现 Emacs tab-line 性能问题的？
作者在打开大量缓冲区（如 Rust 项目 1000+ 文件）时注意到 tab-line 切换明显变慢，于是使用 (profiler-start) 和 (profiler-report) 进行性能分析，从 CPU 使用统计中定位到 tab-line-tabs-fixed-window-buffers 函数及其调用的 seq-position。
这是作者第几次向 GNU/Emacs 贡献代码？有什么特别经历？
这是作者首次向 GNU/Emacs 贡献代码。补丁被接受并将在 Emacs 31.0.51 起收录，作者感到非常兴奋；此外，Richard Stallman 曾在他的邮件线程中评论，但后来表示那是误操作。
