Can't open file with gf/gF for grep result on windows.

[mattn]

Hi list.

Try below:

C:\temp>grep Matsumoto c:/vim/src/*.c > list
C:\temp>vim list

And you can see:

c:/vim/src/gui_w48.c:1228: * forcedly redrawn. (Yasuhiro Matsumoto) */
c:/vim/src/gui_w48.c:1925: /* added for non-MS IME (Yasuhiro Matsumoto) */

Then, type gf or gF on left side at first line. As you know, isfname contains ":" on windows. So vim occur "E447: Can't find file ...".
(NOTE: don't say "you can do it with :cfile", this is a problem about gf/gF)

This is not useful. I wrote a patch for this problem.

https://gist.github.com/mattn/9388140

I tested below:

http://www.google.com/ => HTML content(OK)
http:/ssdfsdf => E447 Can't find file "http:/ssdfsdf" (OK)
http:/ssdfsdf/ => E447 Can't find file "http:/ssdfsdf/" (OK)
p:/ssdfsdf => E447 Can't find file "p:/ssdfsdf" (OK)
p:/ssdfsdf/ => E447 Can't find file "p:/ssdfsdf/" (OK)
_:/ssdfsdf/ => E447 Can't find file "_:/ssdfsdf/" (OK)
_:ssdfsdf/ => E447 Can't find file "_:ssdfsdf/" (OK)
:ssdfsdf/ => E447 Can't find file ":ssdfsdf/" (OK)
c:/vim/src/gui_w48.c:1228: => Open the file(OK)
c:/vim/src/gui_w48.c:1925: => Open the file(OK)
../../../vim/src/gui_w48.c:1925: => Open the file(OK)
:::foo::: => E447 Can't find file ":::foo:::" (OK)

Please check.

Thanks.
- Yasuhiro Matsumoto

[Antonio Giovanni Colombo]

HI everybody,

for what is worth, I strongly agrre with Yasuhiro, and welcome his patch!

Antonio

-- 

      /||\    | Antonio Colombo

  / || \   |  azc...@gmail.com  

 /  ()  \  |  ant...@geekcorp.com  
(___||___) |   az...@yahoo.com

[Bram Moolenaar]

I have also been wondering if we can make "gf" a bit more clever.
I sometimes end up copying a path because its end is not clear.

The way you detect a ":" terminating the name looks a bit too simple.
How about file://c:/path ?
It would be good to add a comment to explain what it's doing at least.

A crude but effective solution would be to first take the longest path,
see if it exists. If not, then try removing a part at the end and try
again. This would require a list of "optional file name characters".
We should not have more than two or three tries to avoid this taking a
long time (it's disk operations, and $PATH can contain many directories).

- Bram

--
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[mattn]

> I have also been wondering if we can make "gf" a bit more clever.
> I sometimes end up copying a path because its end is not clear.
>
> The way you detect a ":" terminating the name looks a bit too simple.
> How about file://c:/path ?
> It would be good to add a comment to explain what it's doing at least.
>
> A crude but effective solution would be to first take the longest path,
> see if it exists. If not, then try removing a part at the end and try
> again. This would require a list of "optional file name characters".
> We should not have more than two or three tries to avoid this taking a
> long time (it's disk operations, and $PATH can contain many directories).

Updated patch: https://gist.github.com/mattn/9388140
(Not modified code, just only add comments)

file://c:path should be worked correctly. The file: URL is passed to netrw,
and netrw open the local paths.
I'm thinking that it don't need to check the file is exists. Do you mean
that the path which contains whitespace?

Thanks.

- Yasuhiro Matsumoto