MacOS 10.12.3
Vim 8.0
scrooloose/nerdtree installed via vundle
Confirmed this bug on my installations.
I believe this is only a problem when the file contains both brackets, with [ followed by ]. I'm not even seeing the file in the NERDTree. #391 may be the same issue.
Hey, @PhilRunninger! I've isolated the bug to the s:UI._stripMarkup() in ui.vim. It was pretty clear that files like this must be treated like flags, so I looked there. I'm fairly confident that line 389 in ui.vim is the source of our problem.
Essentially, anything that looks like [...] is removed from the file name as if it were a flag. This occurs before the user tries to open the file.
I'm not a regular expression wizard yet. Maybe you can take a look.
It looks like line 389 is used to remove the flag that git-nerdtree-plugin puts on, but if foo[bar].txt is not in a git repo, it removes the wrong thing. If we force substitute() to look at the beginning of the word only, then we run into problems with [foo]bar.txt. My initial thought was to use filereadable(), and skip the substitute if it's not needed.
That actually sounds like a good decision for now. It seems more like a temporary fix, because other flags can exist that cause filereadable() to fail. We might need a more "heavyweight" solution for a long-term fix.
I've been hit with this bug and even though I agree that the problem requires a significant change to be rock-solid, but I've found a minimal change that works under the (weak) assumption that flags generally use special characters.
Here's the patch, for those interested:
diff --git a/lib/nerdtree/ui.vim b/lib/nerdtree/ui.vim
index 196d745..07a87e6 100644
--- a/lib/nerdtree/ui.vim
+++ b/lib/nerdtree/ui.vim
@@ -381,7 +381,7 @@ function! s:UI._stripMarkup(line)
let line = substitute (line, '*\ze\($\| \)', "","")
" strip off any generic flags
- let line = substitute (line, '\[[^]]*\]', "","")
+ let line = substitute (line, '\[\W*\]', "","")
let line = substitute (line,' -> .*',"","") " remove link to
Should you be interested in a PR, I'm just a ping away :)
@lifecrisis, I'm thinking about a fix for this issue. What if we used a non-breaking space (ASCII code 160) to delimit the filename from the flags and bookmark label? That character is very unlikely to be used in a filename, and parsing the node's text would be a lot easier. I'll work on it, and throw a PR out for review.
@faaaar @xcambar , would you be willing to test the pull request #868 I've put together for this issue? Details are in the PR. Thanks.
I confirm #868 fixes the issue. Congrats and thanks!
Thanks for confirming this for me. I'll close the issue again when I do the merge.
Most helpful comment
@lifecrisis, I'm thinking about a fix for this issue. What if we used a non-breaking space (ASCII code 160) to delimit the filename from the flags and bookmark label? That character is very unlikely to be used in a filename, and parsing the node's text would be a lot easier. I'll work on it, and throw a PR out for review.