nvim-tree.lua 文件重命名后光标定位问题的分析与解决

在文件管理插件 nvim-tree.lua 中，用户报告了一个关于文件重命名后光标定位异常的问题。本文将深入分析该问题的成因，并介绍其解决方案。

问题现象

当用户在 nvim-tree 界面中对选中的文件或目录进行重命名操作时，如果重命名导致该节点在排序顺序中的位置发生变化，光标不会跟随重命名的节点移动，而是保持原来的索引位置，导致实际上选中了其他文件。

技术分析

问题的根源在于重命名逻辑中的路径处理存在缺陷。在 rename-file.lua 文件的 fn() 函数中，虽然有针对重命名后更新选中状态的代码：

find_file(utils.path_remove_trailing(new_file_path))

但这里的 new_file_path 变量仅包含文件名或部分文件名（取决于用户选择的重命名方式），而不是完整的路径。而实际的 rename() 函数调用时使用的是完整路径：

M.rename(node, prepend .. new_file_path .. append)

这种不一致导致 find_file() 无法准确定位到重命名后的文件，特别是在以下情况：

1. 文件位于深层目录结构中
2. 项目中存在同名文件
3. 使用"e"选项(仅修改扩展名)或"r"选项(修改整个文件名)进行重命名

解决方案

正确的做法是让 find_file() 使用与 rename() 相同的完整路径参数。修改后的代码应如下：

local new_full_file_path = prepend .. new_file_path .. append
M.rename(node, new_full_file_path)
[...]
find_file(utils.path_remove_trailing(new_full_file_path))

这一修改确保了：

1. 无论文件在目录结构中的位置如何变化
2. 无论采用何种重命名方式
3. 无论操作系统平台(Linux/Windows)

光标都能正确跟随重命名后的文件节点。

实现细节

该修复已通过 pull request 提交，主要特点包括：

1. 统一了重命名操作和光标定位的路径处理逻辑
2. 解决了跨平台兼容性问题
3. 支持各种重命名模式（全名修改、扩展名修改等）
4. 保持了原有函数的参数结构和返回值

这个改进显著提升了 nvim-tree.lua 文件管理体验的连贯性和可预测性，特别是在频繁进行文件重命名操作的开发场景中。