On Wednesday, November 9, 2016 at 10:53:08 PM UTC+9, Tony Mechelynck wrote:
> On Wed, Nov 9, 2016 at 2:12 AM, mattn <[email protected]> wrote:
> > On Wednesday, November 9, 2016 at 3:58:03 AM UTC+9, DrChip wrote:
> >> Cesar Romani wrote:
> >
> >> Netrw actually doesn't check that expand("$COMSPEC") is execuable before
> >> setting up g:netrw_localcopycmd; instead, it uses that if netrw reports
> >> has("win32") || has("win95") || has("win64") || has("win16") is true and
> >> that g:netrw_cygwin is false.
> >>
> >> So, what should one use instead of expand("$COMSPEC"), and how do I
> >> detect that condition? The expand("$COMSPEC") stuff used to work, so
> >> presumably Windows has changed things (and I'm primarily a Linux user).
> >>
> >> Alternatively, one may provide substitutes for the various commands:
> >> (ie. the command to be run as a string)
> >>
> >> g:netrw_localcopycmd
> >> g:netrw_localcopydircmd
> >> g:netrw_localmkdir
> >> g:netrw_localmovecmd
> >> g:netrw_localrmdir
> >>
> >> Please let me know what those commands are.
> >
> > Not different from autoload/netrw.vim is defined for. Problem is a checking
> > with executable().
> >
> > BTW, I want to hear the answer from you about permiting to modify your
> > codes to us.
> >
> > I'm thinking that current development speed is so wrong. This is NOT only
> > things about netrw. Many authors of third-party plugin/files are already
> > spoiled to keep development. And they doesn't know how many problems is
> > remaining on vim8.
> > Dr Chip, for example, have you seen this?
> >
> > https://github.com/vim/vim/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20netrw
> >
> > Maybe, the problems occuring on users are not same that you know. I'm
> > guessing that this is a reason that netvim is started. We can implement
> > timer APIs, We can implement job APIs, We can implment channel APIs. But
> > that was slowly to start.
> >
> > We need contribute from users. And I'm thinking that we should be possible
> > to modify bundled files directly. If those are personaly plugin isolated
> > from vim, it won't be a problem. But those are bundled as vim runtime
> > files. So I hope that vim-dev should manage latest version. My opinion may
> > not be a correct answer for this problem. So if you have opinion about
> > this, please let me known.
> >
> > I'm very sorry to trouble you about my rude, but waiting your answer.
> >
> > Thanks.
> > - mattn
>
> On the Windows system where you noticed this problem, is the PATHEXT
> environment variable set? If it is, try clearing it near the top of
> your _vimrc (see ":help executable()").
No, problem is simple.
:echo executable("cmd.exe")
1
:echo executable("cmd.exe /c copy")
0
The command should be specified as filename not with arguments.
Thanks
- mattn
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
