Loading ...
Sorry, an error occurred while loading the content.

Re: Windows doesn't support -f option

Expand Messages
  • Mike Williams
    ... FWIW for me gvim -f does not stop the cmd prompt appearing, while dir ... VIM on Windows 7 x64, 64bit VC10 build. ... Mike -- Make your mark in this
    Message 1 of 16 , May 20 1:54 AM
    • 0 Attachment
      On 20/05/2013 04:53, Ben Fritz wrote:
      > On Sunday, May 19, 2013 10:18:48 PM UTC-5, mattn wrote:
      >> On Monday, May 20, 2013 11:50:08 AM UTC+9, Ben Fritz wrote:
      >>>>
      >>>> I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
      >>>>
      >>>> And cmd.exe really does stop responding when I pass gvim the -f flag.
      >>>> No prompt appears until Vim closes. Any typing done in the cmd.exe
      >>>> window does not appear until Vim closes. When Vim closes, any text
      >>>> typed while Vim was open does appear on the command line.
      >>>>
      >>>> Maybe on Windows the -f is handled elsewhere or something.
      >>>
      >>> Also, I've relied on this behavior in the past, to set gvim as my
      >>> $EDITOR variable used by ClearCase to invoke an external editor to edit
      >>> a config spec with the edcs command. Without this behavior working,
      >>> ClearCase would not be able to wait for Vim to exit and check the file
      >>> for modifications.
      >>
      >>
      >> gvim.exe handle STDIN handle if using dash argument like follow.
      >>
      >> C:\>dir | gvim -
      >>
      >> But -f doesn't do it.
      >>
      >
      > Where did handling STDIN come into the discussion? The original post was
      > that Vim doesn't support the -f option at all in Windows. As I've said, this
      > does NOT seem to be true.
      >
      > It's pretty easy to tell whether or not -f works, because the cmd.exe
      > prompt does really stop and wait for Vim, as does ClearCase, and any other
      > external application I've tried it in.
      >
      > If Vim doesn't support reading from stdin while using -f, that's a different
      > problem. And, it's a different problem I also cannot reproduce. Using your
      > example, "dir | gvim -f -", I see cmd.exe stop responding until Vim exits.

      FWIW for me "gvim -f" does not stop the cmd prompt appearing, while "dir
      | gvim -f -" does (as does the simpler "dir | gvim -") This is latest
      VIM on Windows 7 x64, 64bit VC10 build.

      > Even with the STDIN reading, -f seems to work as intended, whether I invoke
      > gvim from the path (which will find the gvim.bat file installed with Vim),
      > or invoke gvim.exe directly from the installed path under
      > Program Files (x86).
      >
      >> --------------------
      >> C:\vim\src>grep dofork *.c
      >> [SNIP]
      >>
      >
      > I didn't see anything in particular in the output of your grep search for
      > some flag without context, which would indicate specifically that this
      > feature will absolutely not work in Windows.
      >
      > What I do see is very convincing evidence that it DOES work in Windows, by
      > running the program and trying it.
      >
      >>
      >> What version of vim do you use?
      >
      > As mentioned, "Vim without Cream" version 7.3.822, on Windows 7 64-bit.
      >
      > As far as I know, this is a native Windows build, not cygwin or anything
      > else. I relied on the -f feature in Windows before I ever had cygwin
      > installed on my machine. Even now, I never invoke Vim from cygwin, though I
      > occasionally use a cygwin-based compiler as my 'makeprg'.
      >
      > Does it matter what is used to compile Vim? I think (but do not know) that
      > the "Cream" distribution is compiled in MinGW, which I use at home to
      > compile Vim when I'm on Windows. I was under the impression Bram used Visual
      > Studio.
      >


      Mike
      --
      Make your mark in this world or at least spray in each corner.

      --
      --
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Tony Mechelynck
      ... IIUC, the Vim without Cream distribution is compiled under Cygwin (using some MinGW version of gcc distributed by Cygwin) but it doesn t need Cygwin to
      Message 2 of 16 , May 20 2:37 AM
      • 0 Attachment
        On 20/05/13 05:53, Ben Fritz wrote:
        > On Sunday, May 19, 2013 10:18:48 PM UTC-5, mattn wrote:
        >> On Monday, May 20, 2013 11:50:08 AM UTC+9, Ben Fritz wrote:
        >>>>
        >>>> I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
        >>>>
        >>>> And cmd.exe really does stop responding when I pass gvim the -f flag.
        >>>> No prompt appears until Vim closes. Any typing done in the cmd.exe
        >>>> window does not appear until Vim closes. When Vim closes, any text
        >>>> typed while Vim was open does appear on the command line.
        >>>>
        >>>> Maybe on Windows the -f is handled elsewhere or something.
        >>>
        >>> Also, I've relied on this behavior in the past, to set gvim as my
        >>> $EDITOR variable used by ClearCase to invoke an external editor to edit
        >>> a config spec with the edcs command. Without this behavior working,
        >>> ClearCase would not be able to wait for Vim to exit and check the file
        >>> for modifications.
        >>
        >>
        >> gvim.exe handle STDIN handle if using dash argument like follow.
        >>
        >> C:\>dir | gvim -
        >>
        >> But -f doesn't do it.
        >>
        >
        > Where did handling STDIN come into the discussion? The original post was
        > that Vim doesn't support the -f option at all in Windows. As I've said, this
        > does NOT seem to be true.
        >
        > It's pretty easy to tell whether or not -f works, because the cmd.exe
        > prompt does really stop and wait for Vim, as does ClearCase, and any other
        > external application I've tried it in.
        >
        > If Vim doesn't support reading from stdin while using -f, that's a different
        > problem. And, it's a different problem I also cannot reproduce. Using your
        > example, "dir | gvim -f -", I see cmd.exe stop responding until Vim exits.
        >
        > Even with the STDIN reading, -f seems to work as intended, whether I invoke
        > gvim from the path (which will find the gvim.bat file installed with Vim),
        > or invoke gvim.exe directly from the installed path under
        > Program Files (x86).
        >
        >> --------------------
        >> C:\vim\src>grep dofork *.c
        >> [SNIP]
        >>
        >
        > I didn't see anything in particular in the output of your grep search for
        > some flag without context, which would indicate specifically that this
        > feature will absolutely not work in Windows.
        >
        > What I do see is very convincing evidence that it DOES work in Windows, by
        > running the program and trying it.
        >
        >>
        >> What version of vim do you use?
        >
        > As mentioned, "Vim without Cream" version 7.3.822, on Windows 7 64-bit.
        >
        > As far as I know, this is a native Windows build, not cygwin or anything
        > else. I relied on the -f feature in Windows before I ever had cygwin
        > installed on my machine. Even now, I never invoke Vim from cygwin, though I
        > occasionally use a cygwin-based compiler as my 'makeprg'.
        >
        > Does it matter what is used to compile Vim? I think (but do not know) that
        > the "Cream" distribution is compiled in MinGW, which I use at home to
        > compile Vim when I'm on Windows. I was under the impression Bram used Visual
        > Studio.
        >

        IIUC, the "Vim without Cream" distribution is compiled under Cygwin
        (using some MinGW version of gcc distributed by Cygwin) but it doesn't
        need Cygwin to run. Bram uses some MS Visual C/C++ compiler (the same
        one as comes with Visual Studio, but possibly the free version stripped
        of what is not needed when compiling in batch mode under make).

        Best regards,
        Tony.
        --
        SECOND SOLDIER: It could be carried by an African swallow!
        FIRST SOLDIER: Oh yes! An African swallow maybe ... but not a European
        swallow. that's my point.
        "Monty Python and the Holy Grail" PYTHON (MONTY)
        PICTURES LTD

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Ben Fritz
        ... I finally got Visual Studio Express set up on my machine, and compared an executable built from that with one built from MinGW. Neither one supports -f!
        Message 3 of 16 , May 23 6:20 PM
        • 0 Attachment
          On Monday, May 20, 2013 4:37:44 AM UTC-5, Tony Mechelynck wrote:
          > On 20/05/13 05:53, Ben Fritz wrote:
          >
          > > Does it matter what is used to compile Vim? I think (but do not know) that
          >
          > > the "Cream" distribution is compiled in MinGW, which I use at home to
          >
          > > compile Vim when I'm on Windows. I was under the impression Bram used Visual
          >
          > > Studio.
          >
          > >
          >
          >
          >
          > IIUC, the "Vim without Cream" distribution is compiled under Cygwin
          >
          > (using some MinGW version of gcc distributed by Cygwin) but it doesn't
          >
          > need Cygwin to run. Bram uses some MS Visual C/C++ compiler (the same
          >
          > one as comes with Visual Studio, but possibly the free version stripped
          >
          > of what is not needed when compiling in batch mode under make).
          >

          I finally got Visual Studio Express set up on my machine, and compared an executable built from that with one built from MinGW.

          Neither one supports -f!

          Steve, how did you manage to make your Cream builds support -f? I don't need cygwin installed to run Vim, does it depend on some sort of cygwin feature anyway? This would be nice to always have supported!

          --
          --
          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Andrei Olsen
          ... I m a bit baffled as why it works for you. I tried Vim without Cream build 822 and 829 and none of them stop when I pass -f flag from Windows command
          Message 4 of 16 , May 24 8:07 AM
          • 0 Attachment
            kl. 04:17:42 UTC+2 mandag 20. mai 2013 skrev Ben Fritz følgende:
            > I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
            >
            > And cmd.exe really does stop responding when I pass gvim the -f flag. No prompt appears until Vim closes. Any typing done in the cmd.exe window does not appear until Vim closes. When Vim closes, any text typed while Vim was open does appear on the command line.


            I'm a bit baffled as why it works for you. I tried "Vim without Cream" build 822 and 829 and none of them stop when I pass -f flag from Windows command prompt (cmd.exe).

            I should add that -f works fine with any build if I start it from MSYS shell.

            --
            --
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • skeept
            ... I compiled my own vim in windows with visual studio and -f works fine. This is the output of version: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May 22
            Message 5 of 16 , May 24 12:15 PM
            • 0 Attachment
              On Friday, May 24, 2013 10:07:09 AM UTC-5, Andrei Olsen wrote:
              > kl. 04:17:42 UTC+2 mandag 20. mai 2013 skrev Ben Fritz følgende:
              >
              > > I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
              >
              > >
              >
              > > And cmd.exe really does stop responding when I pass gvim the -f flag. No prompt appears until Vim closes. Any typing done in the cmd.exe window does not appear until Vim closes. When Vim closes, any text typed while Vim was open does appear on the command line.
              >
              >
              >
              >
              >
              > I'm a bit baffled as why it works for you. I tried "Vim without Cream" build 822 and 829 and none of them stop when I pass -f flag from Windows command prompt (cmd.exe).
              >
              >
              >
              > I should add that -f works fine with any build if I start it from MSYS shell.

              I compiled my own vim in windows with visual studio and -f works fine.
              This is the output of version:
              VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May 22 2013 17:58:33)
              MS-Windows 64-bit GUI version with OLE support
              Included patches: 1-944
              Compiled by skeept@GLOBAL
              Huge version with GUI. Features included (+) or not (-):
              +arabic +digraphs +libcall +printer -tgetent
              +autocmd -dnd +linebreak +profile -termresponse
              +balloon_eval -ebcdic +lispindent +python/dyn +textobjects
              +browse +emacs_tags +listcmds -python3 +title
              ++builtin_terms +eval +localmap +quickfix +toolbar
              +byte_offset +ex_extra +lua/dyn +reltime +user_commands
              +cindent +extra_search +menu +rightleft +vertsplit
              +clientserver +farsi +mksession +ruby/dyn +virtualedit
              +clipboard +file_in_path +modify_fname +scrollbind +visual
              +cmdline_compl +find_in_path +mouse +signs +visualextra
              +cmdline_hist +float +mouseshape +smartindent +viminfo
              +cmdline_info +folding +multi_byte_ime/dyn -sniff +vreplace
              +comments -footer +multi_lang +startuptime +wildignore
              +conceal +gettext/dyn -mzscheme +statusline +wildmenu
              +cryptv -hangul_input +netbeans_intg -sun_workshop +windows
              +cscope +iconv/dyn +ole +syntax +writebackup
              +cursorbind +insert_expand +path_extra +tag_binary -xfontset
              +cursorshape +jumplist +perl/dyn +tag_old_static -xim
              +dialog_con_gui +keymap +persistent_undo -tag_any_white -xterm_save
              +diff +langmap -postscript -tcl -xpm_w32
              system vimrc file: "$VIM\vimrc"
              user vimrc file: "$HOME\_vimrc"
              2nd user vimrc file: "$VIM\_vimrc"
              user exrc file: "$HOME\_exrc"
              2nd user exrc file: "$VIM\_exrc"
              system gvimrc file: "$VIM\gvimrc"
              user gvimrc file: "$HOME\_gvimrc"
              2nd user gvimrc file: "$VIM\_gvimrc"
              system menu file: "$VIMRUNTIME\menu.vim"
              Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOULYRAMD64/ /Ox /GL -DNDEBUG /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DGLOBAL_IME -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua52.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl516.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=20 -DDYNAMIC_RUBY_DLL=\"x64-msvcr100-ruby200.dll\" -DFEAT_HUGE /Fd.\ObjGOULYRAMD64/ /Zi
              Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:AMD64 /nodefaultlib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:AMD64 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /nodefaultlib:lua52.lib /nodefaultlib:python27.lib WSock32.lib /PDB:gvim.pdb -debug


              and the script I use to build vim is:

              @echo off
              rem To be used on MS-Windows for Visual C++ 2010 Express Edition
              rem aka Microsoft Visual Studio 10.0.
              rem See INSTALLpc.txt for information.
              REM inspired in https://bitbucket.org/rko/vim/src/5e5285bfe982bfc5dbf5dce3a3541b0d3b8f22e7/src/_msvc.bat?at=default
              REM
              REM to compile GvimExt/... should specify CPU=AMD64 after calling this file once
              @echo on

              REM SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
              SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include
              REM SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\Include

              REM call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
              REM call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
              if not defined DID_SOURCE_VCVARS ^
              call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
              set DID_SOURCE_VCVARS=1

              SET VIM_CONFIG_OPTIONS=^
              FEATURES=HUGE OLE=yes MBYTE=yes ^
              IME=yes DYNAMIC_IME=yes GIME=yes ^
              DYNAMIC_PYTHON=yes PYTHON="C:\htemp\Python27" PYTHON_VER=27 ^
              PERL="C:\htemp\Perl64" PERL_VER=516 DYNAMIC_PERL=yes ^
              RUBY="C:\htemp\Ruby200-VC" DYNAMIC_RUBY=yes RUBY_VER=20 RUBY_VER_LONG=2.0.0 ^
              RUBY_PLATFORM=x64-mswin64_100 RUBY_INSTALL_NAME=x64-msvcr100-ruby200 ^
              LUA="C:\htemp\lua" DYNAMIC_LUA=yes LUA_VER=52 ^
              CPU=AMD64 WINVER=0x0500 XPM=no

              nmake -f Make_mvc.mak %VIM_CONFIG_OPTIONS% GUI=no %*
              nmake -f Make_mvc.mak %VIM_CONFIG_OPTIONS% GUI=yes %*

              --
              --
              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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • skeept
              ... OK, I now understand why I claimed that my version supports -f. If I go to the folder where gvim.exe is and run . gvim -f it does NOT support this option.
              Message 6 of 16 , May 26 3:52 PM
              • 0 Attachment
                On Friday, May 24, 2013 2:15:36 PM UTC-5, skeept wrote:
                > On Friday, May 24, 2013 10:07:09 AM UTC-5, Andrei Olsen wrote:
                >
                > > kl. 04:17:42 UTC+2 mandag 20. mai 2013 skrev Ben Fritz følgende:
                >
                > >
                >
                > > > I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
                >
                > >
                >
                > > >
                >
                > >
                >
                > > > And cmd.exe really does stop responding when I pass gvim the -f flag. No prompt appears until Vim closes. Any typing done in the cmd.exe window does not appear until Vim closes. When Vim closes, any text typed while Vim was open does appear on the command line.
                >
                > >
                >
                > >
                >
                > >
                >
                > >
                >
                > >
                >
                > > I'm a bit baffled as why it works for you. I tried "Vim without Cream" build 822 and 829 and none of them stop when I pass -f flag from Windows command prompt (cmd.exe).
                >
                > >
                >
                > >
                >
                > >
                >
                > > I should add that -f works fine with any build if I start it from MSYS shell.
                >
                >
                >
                > I compiled my own vim in windows with visual studio and -f works fine.
                >
                > This is the output of version:
                >
                > VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May 22 2013 17:58:33)
                >
                > MS-Windows 64-bit GUI version with OLE support
                >
                > Included patches: 1-944
                >
                > Compiled by skeept@GLOBAL
                >
                > Huge version with GUI. Features included (+) or not (-):
                >
                > +arabic +digraphs +libcall +printer -tgetent
                >
                > +autocmd -dnd +linebreak +profile -termresponse
                >
                > +balloon_eval -ebcdic +lispindent +python/dyn +textobjects
                >
                > +browse +emacs_tags +listcmds -python3 +title
                >
                > ++builtin_terms +eval +localmap +quickfix +toolbar
                >
                > +byte_offset +ex_extra +lua/dyn +reltime +user_commands
                >
                > +cindent +extra_search +menu +rightleft +vertsplit
                >
                > +clientserver +farsi +mksession +ruby/dyn +virtualedit
                >
                > +clipboard +file_in_path +modify_fname +scrollbind +visual
                >
                > +cmdline_compl +find_in_path +mouse +signs +visualextra
                >
                > +cmdline_hist +float +mouseshape +smartindent +viminfo
                >
                > +cmdline_info +folding +multi_byte_ime/dyn -sniff +vreplace
                >
                > +comments -footer +multi_lang +startuptime +wildignore
                >
                > +conceal +gettext/dyn -mzscheme +statusline +wildmenu
                >
                > +cryptv -hangul_input +netbeans_intg -sun_workshop +windows
                >
                > +cscope +iconv/dyn +ole +syntax +writebackup
                >
                > +cursorbind +insert_expand +path_extra +tag_binary -xfontset
                >
                > +cursorshape +jumplist +perl/dyn +tag_old_static -xim
                >
                > +dialog_con_gui +keymap +persistent_undo -tag_any_white -xterm_save
                >
                > +diff +langmap -postscript -tcl -xpm_w32
                >
                > system vimrc file: "$VIM\vimrc"
                >
                > user vimrc file: "$HOME\_vimrc"
                >
                > 2nd user vimrc file: "$VIM\_vimrc"
                >
                > user exrc file: "$HOME\_exrc"
                >
                > 2nd user exrc file: "$VIM\_exrc"
                >
                > system gvimrc file: "$VIM\gvimrc"
                >
                > user gvimrc file: "$HOME\_gvimrc"
                >
                > 2nd user gvimrc file: "$VIM\_gvimrc"
                >
                > system menu file: "$VIMRUNTIME\menu.vim"
                >
                > Compilation: cl -c /W3 /nologo -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOULYRAMD64/ /Ox /GL -DNDEBUG /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DGLOBAL_IME -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua52.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl516.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=20 -DDYNAMIC_RUBY_DLL=\"x64-msvcr100-ruby200.dll\" -DFEAT_HUGE /Fd.\ObjGOULYRAMD64/ /Zi
                >
                > Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:AMD64 /nodefaultlib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:AMD64 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /nodefaultlib:lua52.lib /nodefaultlib:python27.lib WSock32.lib /PDB:gvim.pdb -debug
                >
                >
                >
                >
                >
                > and the script I use to build vim is:
                >
                >
                >
                > @echo off
                >
                > rem To be used on MS-Windows for Visual C++ 2010 Express Edition
                >
                > rem aka Microsoft Visual Studio 10.0.
                >
                > rem See INSTALLpc.txt for information.
                >
                > REM inspired in https://bitbucket.org/rko/vim/src/5e5285bfe982bfc5dbf5dce3a3541b0d3b8f22e7/src/_msvc.bat?at=default
                >
                > REM
                >
                > REM to compile GvimExt/... should specify CPU=AMD64 after calling this file once
                >
                > @echo on
                >
                >
                >
                > REM SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
                >
                > SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include
                >
                > REM SET SDK_INCLUDE_DIR=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\Include
                >
                >
                >
                > REM call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
                >
                > REM call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
                >
                > if not defined DID_SOURCE_VCVARS ^
                >
                > call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
                >
                > set DID_SOURCE_VCVARS=1
                >
                >
                >
                > SET VIM_CONFIG_OPTIONS=^
                >
                > FEATURES=HUGE OLE=yes MBYTE=yes ^
                >
                > IME=yes DYNAMIC_IME=yes GIME=yes ^
                >
                > DYNAMIC_PYTHON=yes PYTHON="C:\htemp\Python27" PYTHON_VER=27 ^
                >
                > PERL="C:\htemp\Perl64" PERL_VER=516 DYNAMIC_PERL=yes ^
                >
                > RUBY="C:\htemp\Ruby200-VC" DYNAMIC_RUBY=yes RUBY_VER=20 RUBY_VER_LONG=2.0.0 ^
                >
                > RUBY_PLATFORM=x64-mswin64_100 RUBY_INSTALL_NAME=x64-msvcr100-ruby200 ^
                >
                > LUA="C:\htemp\lua" DYNAMIC_LUA=yes LUA_VER=52 ^
                >
                > CPU=AMD64 WINVER=0x0500 XPM=no
                >
                >
                >
                > nmake -f Make_mvc.mak %VIM_CONFIG_OPTIONS% GUI=no %*
                >
                > nmake -f Make_mvc.mak %VIM_CONFIG_OPTIONS% GUI=yes %*

                OK,

                I now understand why I claimed that my version supports -f.
                If I go to the folder where gvim.exe is and run .\gvim -f it does NOT support this option.

                So I realized that when I type gvim in cmd I am actually running gvim.bat which is installed in \windows.
                So if you explicitly run "gvim.bat -f" it should work, but if you run "gvim.exe -f " it shouldn't work.

                Jorge

                --
                --
                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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Ben Fritz
                ... NICE! Thanks for investigating, this was really confusing, and the new note in the help makes it even more so. Testing shows that you re right, of course,
                Message 7 of 16 , May 29 8:07 AM
                • 0 Attachment
                  On Sunday, May 26, 2013 5:52:49 PM UTC-5, skeept wrote:
                  >
                  >
                  > I now understand why I claimed that my version supports -f.
                  >
                  > If I go to the folder where gvim.exe is and run .\gvim -f it does NOT support this option.
                  >
                  >
                  >
                  > So I realized that when I type gvim in cmd I am actually running gvim.bat which is installed in \windows.
                  >
                  > So if you explicitly run "gvim.bat -f" it should work, but if you run "gvim.exe -f " it shouldn't work.
                  >

                  NICE! Thanks for investigating, this was really confusing, and the new note in the help makes it even more so. Testing shows that you're right, of course, and running the Cream build directly from Program Files (x86)\vim\vim73 instead of through the .bat file does NOT support the -f argument.

                  The key is the "/wait" given to the start command (and I assume the "/w" for non-NT systems) in gvim.bat (and other *vim*.bat files added by the installer).

                  The help should probably mention the dependence on a cmd.exe feature in the .bat file rather than native support on Windows, instead of a cryptic "not always supported" note.

                  --
                  --
                  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 vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                Your message has been successfully submitted and would be delivered to recipients shortly.