mini.files: Windows C:// internal paths break LSP file operation filters

[so1ve]

Module

mini.files

Description

On Windows, mini.files appears to use C://... as an internal normalized path form. That can be useful internally, but the same path currently reaches the LSP file-operation flow and breaks per-client file-operation filtering.

In the current implementation, rename actions eventually call vim.uri_from_fname(d.from) / vim.uri_from_fname(d.to) inside the LSP hook. If d.from / d.to are Windows paths in mini.files' internal C://Users/... form, Neovim produces URIs like file:///C://Users/....

Later, mini.files applies each client's workspace.fileOperations.*.filters by converting the URI back with vim.uri_to_fname(...):gsub('\\', '/'). On Windows this remains C://Users/..., which does not match lua_ls' normal filter glob such as C:/Users/Miku/AppData/Local/nvim/**.

As a result, mini.files sends workspace/didRenameFiles with files = {}. lua_ls receives an empty rename list, so its require-path update logic exits early and the expected "Do you want to modify the require path?" prompt never appears.

Minimal reproduction / evidence

Environment:

• Windows
• Neovim 0.12.3
• mini.nvim main at 1345d191bb3da9c7b0e977f4387c5761f9bff68d
• lua-language-server attached to a Lua project rooted at C:/Users/Miku/AppData/Local/nvim

Observed from MiniFilesActionRename event data:

from = "C://Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua"
to = "C://Users/Miku/AppData/Local/nvim/lua/ray/utils/jindows.lua"

Local checks inside Neovim:

local p = "C://Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua"
print(vim.fs.normalize(p))
-- C:/Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua

print(vim.uri_from_fname(p))
-- file:///C://Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua

print((vim.uri_to_fname(vim.uri_from_fname(p)):gsub('\\', '/')))
-- C://Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua

Filter match check:

local glob = "C:/Users/Miku/AppData/Local/nvim/**"
local lp = vim.glob.to_lpeg(glob)

print(lp:match("C:/Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua") ~= nil)
-- true

print(lp:match("C://Users/Miku/AppData/Local/nvim/lua/ray/utils/windows.lua") ~= nil)
-- false

A control workaround using normalized paths triggers lua_ls correctly:

Snacks.rename.on_rename_file(vim.fs.normalize(event.data.from), vim.fs.normalize(event.data.to))

That causes lua_ls to show the expected Modify Require Path prompt.

Expected behavior

mini.files may keep C://... internally if needed, but paths should be normalized/canonicalized before crossing the LSP boundary. In particular, LSP URI construction and file-operation filter matching should use canonical Windows paths like C:/Users/..., not mini.files' internal C://Users/... representation.

Related context

• LSP file-operation support was added in feat(mini.files): make file system actions LSP aware #2340.
• Windows path normalization behavior is related to fix(files): properly normalize root directory on Windows #2277.
• I could not find an existing issue connecting the Windows C:// internal path form with LSP file-operation filtering producing empty files arrays.

[so1ve]

Sorry guys, I asked the agent to investigate this issue, but unexpectedly it directly created an issue using gh cli 😅 I'll create one by hand later

[echasnovski]

I'll create one by hand later

Please do and if it'll happen, please provide a real reproduction steps like "Create these files with these contents, open them, enable certain LSP server (important to note which one), open 'mini.files', rename this file to this name, observe the problem".

But as far as I remember, @TheLeoP did do extra tests on Windows to make sure LSP integration worked there too.

[TheLeoP]

The explanation of the AI doesn't make a lot of sense, but yes, there seems to be a problem with the LSP integration in Windows.

mini.nvim/lua/mini/files.lua

Lines 2704 to 2709 in bf8169f

	H.fs_normalize_path = function(path) return (path:gsub('/+', '/'):gsub('(.)/$', '%1')) end
	if H.is_windows then
	H.fs_normalize_path = function(path)
	return (path:gsub('\\', '/'):gsub('([^/:])/+', '%1/'):gsub('([^:])/+$', '%1'):gsub('^(%a):/+([^/])', '%1://%2'))
	end
	end

Normalizes all Windows paths to C:// (because of #2272). lua_ls always sends globs starting with C:/, so they never match for any path.

On top of that, notifying lua_ls about files starting with C:// results on it not recognizing them and, in turn, not asking Neovim to do any further modifications. So, simply changing C:// to C:/ for the filter check

mini.nvim/lua/mini/files.lua

Line 2873 in bf8169f

local to_fname = H.is_windows and function(x) return (vim.uri_to_fname(x):gsub('\\', '/')) end or vim.uri_to_fname

is not enough.

I guess that the more robust solution would be "de-normalizing" files when first converting them to URIs on

mini.nvim/lua/mini/files.lua

Lines 2844 to 2846 in bf8169f

	if is_create and d.action == 'create' then file = { uri = to_uri(d.to) } end
	if is_delete and d.action == 'delete' then file = { uri = to_uri(d.from) } end
	if is_rename and d.action == 'rename' then file = { oldUri = to_uri(d.from), newUri = to_uri(d.to) } end

Something like

  local files, to_uri =
    {},
    H.is_windows and function(x) return vim.uri_from_fname(x:gsub('^(%a)://([^/])', '%1:/%2')) end or vim.uri_from_fname

diff --git a/lua/mini/files.lua b/lua/mini/files.lua
index 43bcaf8..9037fc7 100644
--- a/lua/mini/files.lua
+++ b/lua/mini/files.lua
@@ -2835,7 +2835,9 @@ H.lsp_fs_hook = function(method, diffs, lsp_timeout)
   -- https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#createFilesParams
   -- https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#deleteFilesParams
   -- https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#renameFilesParams
-  local files, to_uri = {}, vim.uri_from_fname
+  local files, to_uri =
+    {},
+    H.is_windows and function(x) return vim.uri_from_fname(x:gsub('^(%a)://([^/])', '%1:/%2')) end or vim.uri_from_fname
   local needs_check = method == 'willCreate' or method == 'willRename'
   local is_create, is_delete, is_rename =
     vim.endswith(method, 'Create'), vim.endswith(method, 'Delete'), vim.endswith(method, 'Rename')

---

This wasn't caught by our tests on Windows because they were expecting to see C://. It wasn't caught by me because I knew \\ had issues with globs, I didn't know that C:// was also problematic :p

[echasnovski]

On top of that, notifying lua_ls about files starting with C:// results on it not recognizing them and, in turn, not asking Neovim to do any further modifications. So, simply changing C:// to C:/ for the filter check

There are two important questions here:

• Is it only lua_ls thing? I.e. does this reproduce on other (reputable) LSP servers?
• Is there anything in the LSP specification about this case? I'd guess not, but still worth double checking.

[so1ve]

@TheLeoP Thanks for your investigation! I was just trying to create a minimal reproduction of lua_ls, but it seems like I don't need to do that anymore 🫣

@echasnovski I tested this in a rust project and a typescript project, and yes, lsps automatically update their import paths

[echasnovski]

@echasnovski I tested this in a rust project and a typescript project, and yes, lsps automatically update their import paths

Thanks for the follow up!

Then unless there is an easy and non-invasive way of fixing this in 'mini.files', I'd be comfortable to say that this is a known LuaLS limitation. With later opening an issue there about this.

I am also curious about whether emmylua_ls works here.

[so1ve]

I investigated further, and it seems this is indeed an implementation issue with lua_ls - lua_ls defines a glob with a working directory path; while vtsls and rust-analyzer use less stricter ones. However, neo-tree previously integrated well with Snacks.rename.on_rename_file, so I think the internal non-standard windows paths being passed to lsp might be an issue we can fix here