gF fails when &isf contains spec characters

[justinmk]

Using the default vim-fetch settings, gF on foo.py:46: in the following text fails for me (Vim 7.4.618):

foo.py:46:      if(not Directory.Exists(destinationDir)):
foo.py:49:      if(File.Exists(filePath)):
foo.py:54:      if not Directory.Exists(self.PATH_TO_FILES):

Error:

Error detected while processing function fetch#cfile:
line   26:
E447: Can't find file "foo.py:46" in path

Yet :edit foo.py:46 does work.

But :edit foo.py:46: (with colon at the end) fails. These also fail:

call fetch#cfile(0)
call fetch#cfile(1)
call fetch#cfile(2)
call fetch#cfile(3)
call fetch#cfile(4)

If I unmap gF so that the default Vim gF 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't fetch#cfile() work also, instead of using Vim's broken thing?

[kopischke]

Actually, vim-fetch is not using Vim’s gF (it uses gf to fetch the file, then manages the jump on its own). The errors happen independently, albeit for the same reason: foo.py:46 is misidentified as the file name to search for.

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.

[kopischke]

Just to confirm something before I get to investigate further: what is the output of

:echo expand('<cfile>')

at the problematic position?

[justinmk]

Output is

foo.py:46

(lacks the trailing colon)

[kopischke]

The output of the same command on my system is

foo.py

which would indicate that gF fails because your &isf includes :, either because your are on Windows (that would be a new one, I had you pegged as an OS X user ;)), or that you / one your plugins added : to that (default on *nix systems is @,48-57,/,.,-,_,+,,,#,$,%,~,=). If that is the case, the root bug is that I failed to account for how the value of isf could overlay the jump pattern when getting cfile; I might have to catch E447 and parse out possible jump patterns to handle this. Could you confirm that for me by giving me the output of

:echo &isf

please?

I’m not sure why :edit foo.py:46: should fail, however; in my test, both the form with and without the trailing colon work fine, independently of any isf setting (unsurprisingly, I should add, as the pattern detection is independent of Vim file name detection in that case). Could you give me some more details about how it fails exactly? If there is no error message, try logging the output of

:16verbose edit foo.py:46:

to verbosefile and uploading that somewhere for me to see?

[justinmk]

gF fails because your &isf includes :, either because your are on Windows (that would be a new one, I had you pegged as an OS X user ;)),

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.

[kopischke]

No need to confirm the value of isf if you were on Windows – the default there includes :. I’m still very much interested in the exact error / log of the :edit failure, however. In your own time, I’m unlikely to be able to get back to this before next weekend anyway :).

[kopischke]

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

[justinmk]

@kopischke Worth the wait ;)

[wsdjeg]

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.

[igrep]

I'm also very interested in the status of this issue. What's the problem with the fix/gf-isfname branch?