Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot open file or directory whose name include [ or ] #680

Closed
yf4n opened this issue Apr 4, 2017 · 11 comments · Fixed by #868
Closed

Cannot open file or directory whose name include [ or ] #680

yf4n opened this issue Apr 4, 2017 · 11 comments · Fixed by #868
Assignees
Labels

Comments

@yf4n
Copy link

yf4n commented Apr 4, 2017

MacOS 10.12.3
Vim 8.0
scrooloose/nerdtree installed via vundle

@lifecrisis lifecrisis added the bug label Jun 23, 2017
@lifecrisis
Copy link
Contributor

Confirmed this bug on my installations.

@PhilRunninger
Copy link
Member

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.

@lifecrisis
Copy link
Contributor

lifecrisis commented Jun 24, 2017

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.

@PhilRunninger
Copy link
Member

PhilRunninger commented Jun 26, 2017

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.

@lifecrisis
Copy link
Contributor

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.

@xcambar
Copy link

xcambar commented Feb 14, 2018

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 :)

@PhilRunninger
Copy link
Member

@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.

@PhilRunninger PhilRunninger self-assigned this Aug 13, 2018
@PhilRunninger PhilRunninger added the PR Under Review Coding is finished, and a pull request has been created and is being reviewed. label Aug 13, 2018
@PhilRunninger
Copy link
Member

@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.

@xcambar
Copy link

xcambar commented Aug 20, 2018

I confirm #868 fixes the issue. Congrats and thanks!

@yf4n
Copy link
Author

yf4n commented Aug 21, 2018

#868 fixes the issue. thanks!

@yf4n yf4n closed this as completed Aug 21, 2018
@PhilRunninger PhilRunninger reopened this Aug 21, 2018
@PhilRunninger
Copy link
Member

Thanks for confirming this for me. I'll close the issue again when I do the merge.

@PhilRunninger PhilRunninger removed the PR Under Review Coding is finished, and a pull request has been created and is being reviewed. label Oct 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants