Auto compile on save only works if nvim current directory is under .nfnl.fnl file directory.

[Kethku]

After #36 I am able to manually compile and the autocompile on save is working but only works if neovim's current directory is in one that contains the .nfnl.fnl file or a child directory under a directory that contains a .nfnl.fnl file.

I had it in my head that this wasn't a requirement before I updated but it may be I'm misunderstanding it?

[Olical]

This should be the case and I can compile-on-write .fnl files from another working directory. So in my home dir I can open one of nfnl's files and write to it, the changes are reflected in the Lua. Would you be able to share your .nfnl.fnl file? Just in case it's something custom in there?

[Olical]

Is this still an issue for you? Because I couldn't reproduce it earlier, I can try again with the same specific Neovim version as you if you let me know which one you're on. Maybe it's an OS thing though 🤔

[Kethku]

Sorry I took so long to respond here. I'm very confident that this is an os thing. My .nfnl.fnl file is {}

[Kethku]

I'm attempting to fix this once and for all here #42

[Olical]

Ah okay! Thanks for looking into this! I'll take a look at the PR. I should really try and get some sort of nvim setup working on my gaming PC so I can test some things on Windows, not sure where to start really. I thought most people used WSL but that's just a Linux VM so there should be no work there.

Not sure how dotfiles even work for Neovim on Windows? I guess I'd need to write some config from scratch as a test bed because my personal one definitely won't work there.

[UnderCooled]

I'm still using Neovim under Windows, I was switching from "Telescope" to "snacks.picker", then nfnl stop auto compile my fennel files.

my .nfnl.fnl

{:source-file-patterns ["fnl/**/*.fnl" "fnl/*.fnl"]
 :compiler-options {:compilerEnv _G}}

The trust file:

8d59503aec1bd8c594e63b6af664bcb4fc849dbd76f66700031561afe02684ec D:\dev_env\vimconf\nvim\.nfnl.fnl

Telescope picker's behavior:

utils.path_expand({path})                      *telescope.utils.path_expand()*
Hybrid of `vim.fn.expand()` and custom `vim.fs.normalize()`

Paths starting with '%', '#' or '<' are expanded with `vim.fn.expand()`.
Otherwise avoids using `vim.fn.expand()` due to its overly aggressive
expansion behavior which can sometimes lead to errors or the creation of
non-existent paths when dealing with valid absolute paths.

Other paths will have '~' and environment variables expanded. Unlike
`vim.fs.normalize()`, backslashes are preserved. This has better
compatibility with `plenary.path` and also avoids mangling valid Unix paths
with literal backslashes.

Trailing slashes are trimmed. With the exception of root paths. eg. `/` on
Unix or `C:\` on Windows

So the fennel file telescope picked got backslash-ed buffer name, something like

vim.api.nvim_buf_get_name(0)
-- returns: "D:\\dev_env\\vimconf\\nvim\\fnl\\colors.fnl"

Snacks.picker uses vim.fs.normalize(), so in #36, my auto compile works while @Kethku 's not working.

Anyway, let's follow Snacks here, vim.fs.normalize() will translate C:\foo into C:/foo, in

nfnl/fnl/nfnl/callback.fnl

Line 35 in 6bcfdc4

(not (file-path:find "^[%w-]+:/")))

we should use "^[%w-]+://", or C:/foo will match, so the autocmd callback ends early, that's why neovim/neovim#28127 isn't fix the problem.

Now autocmd goes to compile.fnl then fs.fnl, fnl-path->lua-path uses join-path with path-sep = "\\", so replace it with "/".

We are in glob-matches?

nfnl/fnl/nfnl/fs.fnl

Line 102 in 6bcfdc4

(let [regex (vim.regex (vim.fn.glob2regpat (M.join-path [dir expr])))]

vim.fn.glob2regpat() returns a Lua string like this D:[\/]dev_env...., the drive letter separator : will cause mismatch, vim.fn.glob2regpat(M["join-path"]({dir, expr})):gsub(":", "\\:") escape that will finally fix this issue.

[UnderCooled]

And if we use :e foo.fnl, Neovim will convert the path back to backslashes, that will cause fnl\foo.fnl auto compiles to fnl\foo.lua.

So maybe we should add vim.fs.normalize to fnl-path->lua-path:

M["fnl-path->lua-path"] = function(fnl_path)
  fnl_path = vim.fs.normalize(fnl_path)
  return M["replace-dirs"](M["replace-extension"](fnl_path, "lua"), "fnl", "lua")
end

And if users set source-file-patterns in ".nfnl.fnl" to some backslash-ed wildcards like fnl\\**\\*.fnl, maybe we should let users only use / in source-file-patterns, or :gsub() patterns to "normalize" them.

[Olical]

Hm interesting, I'd probably go about adding normalise to the slurp/spit functions which are the points we actually hit the filesystem, that way we can keep paths in whatever format Neovim wants to use internally up until the last moment where we touch a file. I really need to get the tests working under Windows because I have no way to check this otherwise.

[Olical]

Although as you say, maybe we need to normalize earlier so that all the regexes and autocmds work cross platform too, not just the filesystem access.

[Olical]

I'm also thinking the right place to do this might be more like around here

nfnl/fnl/nfnl/compile.fnl

Line 84 in 05d3c15

destination-path (fnl-path->lua-path path)

It's sort of the crux point where we convert paths and perform IO things that all of the functions pass through, I think. So rather than forcing a normalize in fnl-path->lua-path (which I think the user can re-configure!) we should do it in this function to make sure all paths we're working with are consistent. I think.

Although it's really hard to tell without a Windows machine to test on, always makes things like this difficult, sorry.

[UnderCooled]

Maybe just make sure Windows file path matches the destination path?
Like this

{:source-file-patterns ["fnl/**/*.fnl" "fnl/*.fnl"]}
; mock up a source path:
"C:\\foo\\fnl\\bar\\baz.fnl" ; if it has been normalized "C:/foo/fnl/bar/baz.fnl"
; Correct destination path:
"C:/foo/lua/bar/baz.lua"

They are just strings, you may not need a Windows machine.
After you normalize the path, the two bugs I said earlier are all about that drive separator (":").
"^[%w-]+:/" - > "^[%w-]+://" in callback.fnl
vim.fn.glob2regpat not escape ":"

---

When you read file content with core.spit, this destination ("C:/foo/lua/bar.lua") works fine.
Here's my local nfnl modifications, I patched Lua files to make sure not breaking any fennel stuff :P

diff --git a/lua/nfnl/callback.lua b/lua/nfnl/callback.lua
index c09e7b1..0875f4d 100644
--- a/lua/nfnl/callback.lua
+++ b/lua/nfnl/callback.lua
@@ -23,7 +23,7 @@ end
 local function supported_path_3f(file_path)
   local _4_
   if core["string?"](file_path) then
-    _4_ = not file_path:find("^[%w-]+:/")
+    _4_ = not file_path:find("^[%w-]+://")
   else
     _4_ = nil
   end
diff --git a/lua/nfnl/fs.lua b/lua/nfnl/fs.lua
index 686ea9b..4cd05d8 100644
--- a/lua/nfnl/fs.lua
+++ b/lua/nfnl/fs.lua
@@ -82,7 +82,7 @@ M["path-sep"] = function()
   if (("linux" == os) or ("osx" == os) or ("bsd" == os) or ((1 == vim.fn.exists("+shellshash")) and vim.o.shellslash)) then
     return "/"
   else
-    return "\\"
+    return "/"
   end
 end
 M.findfile = function(name, path)
@@ -110,10 +110,11 @@ M["replace-dirs"] = function(path, from, to)
   return M["join-path"](core.map(_13_, M["split-path"](path)))
 end
 M["fnl-path->lua-path"] = function(fnl_path)
+  fnl_path = vim.fs.normalize(fnl_path)
   return M["replace-dirs"](M["replace-extension"](fnl_path, "lua"), "fnl", "lua")
 end
 M["glob-matches?"] = function(dir, expr, path)
-  local regex = vim.regex(vim.fn.glob2regpat(M["join-path"]({dir, expr})))
+  local regex = vim.regex(vim.fn.glob2regpat(M["join-path"]({dir, expr})):gsub(":", "\\:"))
   return regex:match_str(path)
 end
 local uv = (vim.uv or vim.loop)

These modifications work fine in all the following cases:

1. pwd in (.nfnl.fnl root)/fnl, saving (.nfnl.fnl root)/fnl/foo.fnl compiles to (.nfnl.fnl root)/lua/foo.lua.
2. pwd in somewhere else, source pattern matched without any problem because correctly escape ":" in vim regex.
3. using vim.fs.normalize, no matter which path separator Neovim uses in buffer name, it will work.

[Olical]

The function you're suggestion the modifications to around returning / instead of a backslash was deliberately added by Windows users because we needed to use \\ for them for some reason. I'm kinda confused about this now, I thought we couldn't use forward slashes in Windows paths except when manipulating them inside Neovim? Maybe it's a difference between WSL and actual full Windows? Although I guess WSL uses full Linux paths because WSL is just an Ubuntu VM and isn't anything more special than that from what I understand.

I'll need to try and get tests working on Windows I think but that proved EXTREMELY difficult in #42 and we got blocked by a Windows specific Neovim bug that we couldn't work around sadly.