-
Notifications
You must be signed in to change notification settings - Fork 17
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
gF fails when &isf contains spec characters #9
Comments
Actually, vim-fetch is not using Vim’s In the case of the plugin this seems to be due to an error in the jump pattern regex. I’ll try to get to the root of this as soon as I am at my machine again, which might not be in the next few days, though – sorry about that. |
Just to confirm something before I get to investigate further: what is the output of :echo expand('<cfile>') at the problematic position? |
Output is
(lacks the trailing colon) |
The output of the same command on my system is foo.py which would indicate that :echo &isf please? I’m not sure why :16verbose edit foo.py:46: to |
Yes, I was on Windows :) I use all of win/osx/unix on a regular basis. I'll try to isolate it when I get back to a Windows machine. |
No need to confirm the value of |
@justinmk I am at long last getting to handling this (turns out it necessitates a lot of refactoring to solve cleanly). Watch out for release 2.1. |
With default &isf settings, this is currently only relevant for Windows and specs using a “:” as separator, but this should also handle custom &isf settings (e.g. when the parens are included). Fixes #9.
With default &isf settings, this is currently only relevant for Windows and specs using a “:” as separator, but this should also handle custom &isf settings (e.g. when the parens are included). Fixes #9.
With default &isf settings, this is currently only relevant for Windows and specs using a “:” as separator, but this should also handle custom &isf settings (e.g. when the parens are included). Fixes #9.
@kopischke Worth the wait ;) |
I start to use Windows os. in my plugin flygrep, I get same error, and I have fixed it. so I will do it here. |
I'm also very interested in the status of this issue. What's the problem with the |
Using the default vim-fetch settings,
gF
onfoo.py:46:
in the following text fails for me (Vim 7.4.618):Error:
Yet
:edit foo.py:46
does work.But
:edit foo.py:46:
(with colon at the end) fails. These also fail:If I unmap
gF
so that the default VimgF
is used, it also fails with the same error. I'm guessing this is the problem, but since:edit foo.py:46
works, why can'tfetch#cfile()
work also, instead of using Vim's broken thing?The text was updated successfully, but these errors were encountered: