Closed ReneFroger closed 10 years ago
I'll look into it, thanks for the report. Does it happen with both got
and gof
?
decides to open the home folder
That's what happens with start explorer ...
has no idea where to go.
gof
seems to work fine with mapped drives and UNC paths. Are you using got
? gvim, mintty, ...? Can you give an example absolute path that you are editing?
Here's what I've found. Testing with:
S:\Users\foo
\\corp.innotech\files\users\foo
or \\1.2.3.4\c$
got
and gof
work fine.gof
works fine.got
at a UNC path (not a mapped network drive) has a problem: '\\corp.innotech\files\users\foo'
CMD does not support UNC paths as current directories.
cmd.exe
literally cannot cd
to UNC paths. This affects msysgit bash since we cd
before starting bash to avoid the bash-within-bash hack. Functionality is more important than avoiding that hack, though, so I'll try to work around.
start /D
parameter has the same issue.let g:gtfo#terminals = { 'win' : 'powershell -NoLogo -NoExit -Command' }
@ReneFroger Would still like to hear your scenario in case it is different than the notes I have collected. I have not found any problems with mapped drives but you seem to indicate here that you had a problem:
minor issues when you're editing the files on shared directory/folders (if folders, they're mapped to a drive).
Sorry for my belated response. Busy with work. Thanks for your response.
Now I'm home. I use Gvim 7.4 32-bit under Windows x64-bit.
With got (Justin, how could you change the font/colors/everything for commands, to differentiate commands from regular text? I couldn't find it in the markdown manual). , I get Mingw32 opened (was installed earlier). With got, opens the correct directory /z/folder/.... With gof, he don't open the correct directory. Instead, he opens the default directory. That was it when I tried it on my work.
But now I'm home, I tried again on the shared folder that I use too on my work. Something weird happened. With gof he opened the correct directory.
The address path of the shared folder is d$ (\some-label-here), which is mapped to Z:.
I will try it tommorow when I'm back on my work, to be sure this is not a glitch.
I still have the same problem on my work, the problem occurs not only on shared folders, but on local folders (not shared folders) too, like C:\example.
One thing is different from my home situation. Here we use Windows 7 32-bit. But I don't think it's gonna make any difference for the workings of this plugin.
Any tips?
@ReneFroger What is the output of
:echo bufname("%")
:echo expand("%:p")
on a buffer where this occurs? Might be the same issue as #21.
:echo bufname("%")
gives me only the filename of the buffer: example.php
.
:echo expand("%:p")
gives me the full path: Z:\websites\intranet-development\applications\my-application\test\core\php\example.php
.
When I open both files in Windows Explorer, they appeared with same path as described above.
The exact output is important, specifically, does it have double slashes \\
?
No, the path as echoed doesn't have any double slashes.
@ReneFroger What is the output of:
verbose set shell
It would be helpful if you could add the following debugging line to vim-gtfo\autoload\gtfo\open.vim
, in the func! gtfo#open#file(path)
function, right after the elseif s:iswin
condition:
elseif s:iswin
echom '!start explorer '.(l:validfile ? '/select,"'.l:path.'"' : l:dir)
Then what does it show for one of the paths for which you have this issue? (You can view the output using :mes
command)
Committed a change which may help. Can you try the latest?
Thanks for your kind help, much appreciated! I downloaded your latest version. Which didn't help.
Then I edited func! gtfo#open#file(path), which is located on line118, with:
elseif s:iswin
echom '!start explorer '.(l:validfile ? '/select,"'.l:path.'"' : l:dir)
Nothing more. But the ':message' gives me no other information or output, than only Messages maintainer: Bram Moolenaar Bram@vim.org and the current filename that's opened. But I get that too, when I don't use gof
command.
As the problem occurs too on non-shared folders, like files in my documents and this issue arise only on my work pc, I guess it had something to do with the path on these PC. At end of the day, I will make a screencast, if that may make things more clear.
Then I edited func! gtfo#open#file(path),
Echom should print to :mes when you invoke gof
. Did you restart vim first?
I changed the following lines:
The selected rows are the lines that are changed. Then I saved it, restarted Vim. Then I open C:\Dropbox\Vim.vim\setup\general.vim with Unite.
I press gof
, and get the folder My Documents instead. When I type :message
, I get only this output.
On my home, I have no issues with Gof on same directory. I find that weird.I suspect something inside my Vim setup is causing this, related to the work environment. I will test it again with empty Vimrc later, when I'm home again and then connect to my work pc. Thanks in advance for your help and patience!
@ReneFroger We're close to a solution. What is the output of these commands:
:echo executable('cygstart')
:echo has('win32') || has('win64')
:echo &shell
On home pc (Windows 7 x64, Gvim 7.4), where gof
is working correctly,
:echo executable('cygstart')
gives me 0.
:echo has('win32') || has('win64')
gives me 1.
:echo &shell
gives me C:\Windows\system32\cmd.exe
On work pc (Windows 7 32 bit, x86, Gvim is identical, theyre stored in Dropbox) is not working correctly.
:echo executable('cygstart')
gives me 1, which is differently.
:echo has('win32') || has('win64')
gives me 1.
:echo &shell
gives me C:\Windows\system32\cmd.exe
Yep, I didn't plan for executable('cygstart')==1
in gvim. I have a fix, will push by tomorrow.
Great to know that there is a possible solution, will look foward to your fix!
Thanks a lot for all of your efforts for the Vim community, I donated some bitcoins too for Neovim development.
@ReneFroger Should be fixed, let me know how it goes.
Just tested the new version on my work... Great, it works perfectly!
Thanks for the support! And all the best.
Nice plugin, thanks for sharing it with us!
Works fine on Windows. I noticed there are some minor issues when you're editing the files on shared directory/folders (if folders, they're mapped to a drive).
Then the plugin couldn't find the folder on shared directory which where the files are open in the Vim buffers. Instead, he decides to open the home folder (which is located on C:).