告别插件堆砌！Neovim 配置“瘦身”实战：用 Mini.nvim 替换主流插件

转Reddit技术博主的帖子：我的 Neovim 插件哲学

作为一名资深的系统程序员，我日常工作会处理大型的单体代码仓库（monorepos），项目文件数超过 4 万，代码行数超过 400 万。在这样的环境下，我对开发工具的要求是：极简、高效、启动快。

我的插件哲学是：尽可能少用插件，尽可能少用花哨功能，只保留工作必需的核心特性。

我对 Mini.nvim（或者任何类似的 Neovim 功能标准库）的理念非常认同。它提供了一套几乎是所有 Neovim 用户都需要的基础功能，而这些功能可能还不适合直接集成到 Neovim 核心中。我认为，一个现代化的编辑器不应该要求用户“从零开始”，四处搜寻并盲目安装 10 到 20 个主流插件才能获得一套完整的功能。

这次尝试，我就是想看看能否用 Mini.nvim 替换掉我配置中那些“常规”的插件，实现一次彻底的配置“瘦身”。

注意： 我目前使用 Neovim Nightly 版本，并继续使用 pack 进行插件管理（不切换到 Lazy 或 Packer 等），这个依赖管理方式不会改变。

插件对决：Mini.nvim vs. 常规插件

接下来，我将按照功能模块，逐一分享我使用 Mini 系列插件替换主流插件的体验和决定。

1. 文件浏览器 (File Explorer)

体验与分析：

Mini.files 倾向于使用浮动窗口 (popup window) 来显示文件列表，这是我遇到的第一个主要“痛点”。在我看来，文件浏览这种功能，在普通缓冲区 (normal buffer) 中展示才更合理，或者至少应该提供在缓冲区中打开的选项。

浮动窗口的弊端： 使用浮动窗口意味着：预览窗口会不断地向右侧移动和重新调整大小，眼睛需要频繁横跨屏幕；打开文件需要按两次键（l 和 q），而不是使用更直观的 <Enter> 同时完成打开文件和关闭界面的操作。

我的结论： 虽然浮动窗口在需要同时打开多个分屏的特定场景下有用，但对我来说，全缓冲区的视图才是更主流、更高效的工作方式。因此，我保留了 Oil.nvim。

2. 会话管理 (Session Management)

体验与分析：

我过去不得不自己编写一些 Vimscript/Lua 来实现本地会话管理。Mini.session 成功地让我抛弃了这些自定义代码，这是一个重大的改进，切换成功。

3. 启动页 (Startup Screen)

体验与分析：

Mini.starter 使用 Lua 编写，更加极简，完全能够满足启动页的需求，我非常喜欢，切换成功。

4. 模糊查找器 (Fuzzy Finder)

体验与分析：

Mini.picker 仍然采用了浮动窗口。虽然 Mini.files 提供了侧边预览（但有上述问题），但 Mini.picker 却没有侧边栏的文件预览（虽然可以通过 <Tab> 深入预览）。

一致性问题： 在文件列表中选择文件时需要侧边预览，但在模糊查找文件名时却不需要？我感到这种设计不一致。

界面空间浪费： 当我查找文件时，我的主要目标是看到查找器和文件预览，不需要看到后面已经打开的六个窗口。浮动窗口在模糊查找时浪费了大量的屏幕空间。

性能： 在处理某些任务时，我感觉 Mini.picker 略慢于 fzf-lua。

尽管我很想为了减少依赖而切换，但考虑到体验和性能，我最终没有切换。

5. 词语高亮 (Word Highlighting)

体验与分析：

功能完全一致，即插即用，轻松获胜，切换成功。

6. 键位提示 (Keymap Hint)

体验与分析：

Mini.clue 提供了很多默认的可选键位映射，并且设计上极简。这是一个小小的浮动窗口真正发光发热的领域，因此我切换成功。

7. Git 核心操作 (Git Wrapper)

体验与分析：

我不理解 Mini.git 文档中提出的哲学观点：Git 封装器应该只关注当前缓冲区的“工作集”。

逻辑矛盾： Git 是在仓库/索引级别工作的。为什么我们不应该关心那些可能被暂存（staged）但未在当前缓冲区打开的文件？如果我在当前缓冲区添加了代码块（hunks），我肯定想查看整个 Git 索引状态。

工作流割裂： 作者似乎建议使用 lazygit 来查看索引，但这又带来了工作流的割裂。如果 fugitive 的 :G 视图已经能让我们在 Neovim 中完成大部分简单的 Git 流程，为什么还要拆分？

出于对完整 Git 工作流的需求，我没有切换。

8. Git 侧边标记 (Git Signs)

体验与分析：

小问题： 尽管文档声称默认使用行号列（number column），但它却默认使用了标记列（sign column）。我需要手动设置才能符合预期。

键位绑定问题： 它似乎自动添加了以 g. 开头的键位绑定。我强烈反对插件在未经我明确要求或手动配置的情况下，自动添加键位绑定。

保留原因： 我最终保留了 Mini.diff，仅仅是因为我喜欢使用行号列来标记 Git 差异代码块（hunks），从而将标记列专门留给 LSP 诊断信息。

9. LSP 通知与诊断 (LSP Notifications)

体验与分析：

Mini.notify 的一个关键问题是：通知文本默认不进行对齐（justified）。

可读性问题： fidget 会将文本对齐到虚拟文本（virtual text）所在的一侧。Mini.notify 缺乏对齐，使得快速滚动的文本难以阅读。

定制化困境： 我原本非常看好这个小型功能。但为了让它正常工作并正确格式化 LSP 文本，我感觉自己需要编写的代码量，几乎可以自己创建一个新的浮动窗口了。

实际效果： 在大型项目、或是有错误的工程中观察 LSP 加载和报错信息时，Mini.notify 在传达正在发生的事情方面基本无用。

因此，我没有切换。

使用过程中的小槽点 (Nits)

在使用 Mini.nvim 插件集的过程中，我也发现了一些可以改进的小地方：

默认启用图标

所有的 Mini 插件默认都启用图标。要知道，图标需要打了补丁的字体（patched fonts）。

令人不解的是，禁用图标的配置方式非常复杂，需要传递一个完整的函数（例如 content = { prefix = function() end }），而不是简单的 icons = false 这样的布尔值开关。

文档问题

部分文档内容有些冗长，偶尔难以跟进其思路，但总的来说还是能找到所需信息。

值得称赞的是，MiniMax 的功能对比部分甚至比官方文档更有帮助，尤其是其提供的功能集与主流插件的对比非常实用。

总结：总体评估与未来展望

通过这次“配置瘦身”尝试，我得出了以下结论：

小型插件的胜利： 我非常满意地用 Mini 版本的插件替换掉了好几个小型功能插件（如启动页、词语高亮、键位提示等）。

核心功能仍需完善： 对于一些核心且复杂的功能（如文件浏览、模糊查找、Git 核心操作），我感到有些遗憾，因为它们仍无法替换掉我习惯使用的那些主流插件。

未来展望： 如果 Mini.nvim 能够解决我提到的这些“小槽点”（特别是浮动窗口的默认行为、通知文本的对齐和默认图标设置），我非常乐意尝试构建一个完全基于 Mini 的 Neovim 配置。

Mini.nvim 的理念是正确的，它正在朝着构建一个更合理、更集成化的 Neovim 基础配置迈进，我期待它的后续发展。