Port fzf#shellescape to fix escaping issues in Windows

[janlazo]

Initial work to fix all escaping issues for Vim and Neovim in Windows. tempname is necessary to bypass Vim's regular shellescaping in both s:system and s:bang like in Vim plugin of fzf because regular Vim seems to assume that the shell options are unchanged in Windows even if all but shell are unset. It's possible to not require batchfiles but it means double-escaping (ie. fzf#shellescape(fzf#shellescape(cmd)) ) for Vim and single-escaping for Neovim with the same values for shell options.

[janlazo]

This looks like s:bang now but %#! are not escaped.

[janlazo]

s:spawn needs tempname for the jobs for the same reasons on system and :!, especially in regular Vim 8.

[janlazo]

@junegunn Do I have to update the python and ruby jobs?

[junegunn]

Do I have to update the python and ruby jobs?

No, we don't want to spend more of our time on those legacy installers.

So this fixes #606, right? It's not clear to me though how using a batchfile instead of a command string suppresses "Enter key" prompt. Can you explain? Thanks.

[janlazo]

This PR targets #635, #668, #539 (shell points to $SHELL), Case 1 in https://github.com/junegunn/vim-plug/wiki/faq#windows-system-error-e484.

For 606, appending silent to the bang command in s:bang (see #606 (comment)) is enough. The trick to get around the prompt works but the external shell remains open. I don't know if this is required for MacVim as well.

[junegunn]

This PR targets #635, #668, #539

Thanks for the clarification. I completely lost track of those issues, largely because I'm not a Windows user. Can you update the commit message with Close #xxx lines so that those issues are automatically closed when this is merged?

I just reviewed the code, although it's unfortunate that we have to introduce extra code branches here and there for Windows, the change looks good to me. Is there anything else you want to address?

[janlazo]

Can you update the commit message with Close #xxx lines so that those issues are automatically closed when this is merged?

I'll rebase when I think it's ready.

Is there anything else you want to address?

I prefer vim-plug to use cmd.exe only in Windows so the side effects of setting SHELL before Vim runs should be reverted for system to work properly. This is for #539 and for handling SHELL in cmd.exe or powershell.

[janlazo]

@junegunn do you want the fix for #606 in here or in a separate PR? Also, do you want to keep the old s:shellesc as fallback instead of shellescape?

[janlazo]

@junegunn Unlike fzf's Vim plugin, shell is not set at the start so s:shellesc may not work as expected. To guarantee that it will work in the batchfile, I think it's better to make it non-configurable. It's the same loophole in fzf#wrap because shell is not passed to fzf#shellescape.

if has('win32')
  function s:shellesc(arg)
    return s:shellesc_cmd(a:arg)
  endfunction
else
  function s:shellesc(arg)
    return shellescape(a:arg)
  endfunction
endif

[junegunn]

do you want the fix for #606 in here or in a separate PR?

As long as it's on a separate commit, I'm fine with either :) By the way, we are going to apply silent only on GVim, right? As you did in #606 (comment). On terminal Vim, it messes up the screen and requires additional :redraw!.

do you want to keep the old s:shellesc as fallback instead of shellescape?

No, you properly handled escaping issues on Windows, so I guess that crude solution is no longer needed.

[junegunn]

Reviewed the code and it looks good to me. Thanks, again. I see that you rebased your commits, ready for merge?

[janlazo]

As long as it's on a separate commit, I'm fine with either :) By the way, we are going to apply silent only on GVim, right?

Yes. I'll open a separate PR for #606 after the merge.

ready for merge?

Yes for Windows unless you want to handle msysgit or cygwin as well.

[junegunn]

Thanks, I really appreciate your contribution.

[janlazo]

@junegunn Do you know why some s:system calls use s:esc for tags, branches instead of s:shellesc? Backslash escaping doesn't work in cmd.exe so any argument with spaces must be quoted. In an interactive session, cmd.exe autocompletes paths with spaces by wrapping it in double quotes. Powershell does the same but with single quotes.

I traced it to eb47183 from the blame. I don't use tags or branches so I didn't notice this while working on this PR.