fix: files not recognized if their parent dir starts with a special char

[suitablebeard]

I noticed that whenever I tried to open a file with Fuzzbox inside the directory '/Docs/+ new notes/' it kept opening brand new files.

The bellow explains what exactly the issue is. Here, I use the plus symbol as an example but this also happened with others.

(extracted from my commit message)

To better understand this, let's say we have a file with this path: /notes/+/file.md.

Since the functions for opening files try to make the filepaths relative to the cwd, there are cases where a filepath might start with a special character. After such character is escaped, the execute command runs something similar to this:

exec "edit \+/file.md"

The problem is that the exec command seems to read the backslash as a directory indicator and thus creates a file not relative to the cwd but rather in the root directory. In Windows, this becomes the path for the file

C:\+\file.md

which can be seen with echo fnamemodify(expand('%'), ':p')

Now I see two solutions:

1. change the filename-modifiers to just ':p:~' (full path relative to home);
2. prepend the path in the exec with a './' (explicitly indicates the filepath is relative to the cwd)

I chose solution 1.

[mmrwoods]

Hi, thanks for looking into this and opening a PR :-)

I think the issue here is with fnameescape() and a leading +, which has a special meaning with :edit and friends and is therefore escaped.

Removing the :. filename modifier from fnamemodify() will fix it, but at the cost of not opening files relative to the current working directory, which causes other problems (e.g. not showing file path relative to working directory on status line when opened from fuzzbox).

If you remove the fnamemodify() entirely but retain fnamescape() does it still cause problems? I suspect it will, dependent on what is used to get the list of files and what that returns.

The answer here might be to extract a function to get the file path to open, and make it aware of leading + and >, which have a special meaning when opening files, and in those cases remove the :. from the filename modifiers.

[mmrwoods]

Hi,

Found a little time to do some testing and as expected this only seems to affect Windows, the problem is the fnameescape() escaping the leading + in the path, and your change does fix it, but with side-effects I'd prefer to avoid.

I'll take another look when I have some time tomorrow and try to get a fix based on your change merged.

Thanks

[mmrwoods]

This should be fixed now in main, I've just applied your fix conditionally, only when necessary (is windows and path starts with + or >). Thanks for your contribution, it's not something I would ever have spotted 👍