refactor: use builtin path functions

[kkanden]

this PR aims to unify path manipulation around the codebase both to ensure consistency and compatibility on all platforms using vim.fs and vim.uv function where appropriate.

i'll make commits limited to files or in larger batches to make debugging and reviewing easier.

[kkanden]

i'll try to get the rest done tomorrow or later if there's not enough time. many of the path joins using .. are probably fine once we have ensured that paths are normalized but for the sake of consistency i'm gonna try to turn everything into vim.fs.joinpath. if you'd like for me to leave the simple path joins as is then let me know :)

[kkanden]

i think this covers it all. please do let me know if i wasn't too eager with the use of vim.fs.joinpath.

i wasn't too sure what to do in rnw.lua#355 and rnw.lua#396 (SyncTex_get_master and SyncTex_backward). it seems to me there's some synctex-specific manipulation being done so i left it as is. after that is resolved the normalize_windows_path function from utils could be retired in favor of just vim.fs.normalize.

[PMassicotte]

Thank you for your contribution!

A few points to validate:

• vim.fs.rm throws an error if the file is already gone, i.e., quitting R and then Neovim causes the exit cleanup loop to crash mid-way, leaving temp files behind.
• If R crashes before it finishes starting up, clear_R_info tries to delete files that were never created, throws, and skips resetting R.nvim's internal state.
• A user with compldir = "$HOME/.local/R.nvim" in their config gets a literal directory named $HOME created in their cwd instead of their actual home directory path.

[PMassicotte]

To verify: M.normalize_path(path) return vim.fs.normalize(path) end

vim.fs.normalize tidies up a path but it does not make relative paths absolute. Pass foo.R and you get back foo.R.

The function is used in workspace.lua and references.lua to build cache keys and compare file locations. Have to make sure it does not break things with the LSP.

[kkanden]

thanks a lot for the feedback!

• ad. vim.fs.rm: we can either stick to vim.fn.delete for the sake of simplicity or we could make a wrapper that first checks if the file exists and then delete it. i'm fine with either.
• ad. compldir: i'm pretty sure that is caused by executing set_directories (inside do_common_global) before user options are merged with the default config (config.lua lines ~ 1198-1208). from what i've tested, environment variables are not expanded on the main branch either.
• ad. normalize_path: that is an oversight on my side. i can wrap fnamemodify in fs.normalize or leave it as is since it seems to work correctly.

[jalvesaq]

I will be able to try the changes only on Saturday. For now, just two observations after quickly looking at the changes:

sumatra.lua is used only on Windows because SumatraPDF is a Windows-only application. Hence, it's simpler to hardcode the backslash.

In code such as this:

vim.fs.joinpath(config.remote_compl_dir, "tmp/bo_code.R")

there is a forward slash that isn't being normalized.

[kkanden]

as per :help vim.fs.joinpath slashes in the arguments are normalized:

vim.fs.joinpath({...})                                     *vim.fs.joinpath()*
   [...]
    Examples:
    • "foo/", "/bar" => "foo/bar"
    • "", "after/plugin" => "after/plugin"
    • Windows: "a\foo\", "\bar" => "a/foo/bar"

[kkanden]

i have reverted the change in lsp/utils.lua and some of the path joins in pdf/sumatra.lua. for the rest of the issues, i'll wait for your opinion on how to resolve them best :)

[PMassicotte]

Hi and thank you. I will be back to my office tomorrow; I will have more time to dig in :)

[PMassicotte]

It seems to be working on my side, but I do not have access to a Windows machine. @jalvesaq, have you ?

[jalvesaq]

It seems to be working on my side, but I do not have access to a Windows machine. @jalvesaq, have you ?

No. I uninstalled the virtual machine months ago because it was too slow.

[PMassicotte]

It seems to be working on my side, but I do not have access to a Windows machine. @jalvesaq, have you ?

No. I uninstalled the virtual machine months ago because it was too slow.

Maybe we could use CI to do at least some basic checks on a Windows machine.

[kkanden]

i used this branch a but on my windows machine and encountered no issues. couldn't test the whole functionality tho.

[PMassicotte]

@kkanden thank you for the changes. Are you working on Windows? If so, do you have any issue? I am asking because start_rnvimserver uses ";" when config.is_windows is true, but MinGW/MSYS2 shells use ":" as the PATH separator.

[kkanden]

my work laptop is on windows and in vim.uv.os_uname() it shows up as mingw32. the lsp worked fine despite that.