E194: No alternate file name to substitute for '#' on win 7

[chtenb]

Explain the issue

I installed vimtex on a windows 7 machine. When I try to compile, an unexpected error is given.

Reproduce:

1. Open a tex file with vim and press \ll to compile.
2. Expected: The tex file is compiled
3. Actual: Error is given

Error detected while processing function vimtex#compiler#compile[5]..399[24]..401[39]..517[5]..522:
line    4:
E194: No alternate file name to substitute for '#': !start /b "cmd /s /c "set max_print_line=2000 & latexmk -verbose -pdf -file-line-error -synctex=1 -interaction=nonstopmode -pvc -e "$success_cmd = '""""""C:\Program Files\Vim\vim74\gvim.exe"""""" --servername "GVIM" --remote-expr "vimtex#compiler#callback(1)"'" -e "$failure_cmd = '""""""C:\Program Files\Vim\vim74\gvim.exe"""""" --servername "GVIM" --remote-expr "vimtex#compiler#callback(0)"'" "main.tex" >C:\Temp\VIA9F32.tmp""

Minimal working example

\documentclass{minimal}
\begin{document}

Hello World!

\end{document}

Minimal vimrc file

set nocompatible

" Load Vimtex
let &rtp  = '~/.vim/bundle/vimtex,' . &rtp
let &rtp .= ',~/.vim/bundle/vimtex/after'

" Load other plugins, if necessary
" let &rtp = '~/path/to/other/plugin,' . &rtp

filetype plugin indent on
syntax enable

" Vimtex options go here

let g:vimtex_view_general_viewer = 'C:\\Program Files\\SumatraPDF\\SumatraPDF.exe'

[lervag]

Which version of Vim are you on?

@fuzzybear3965 Are you by any chance able to reproduce this?

[chtenb]

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 11 2015 11:38:48)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-965
Compiled by veegee@veegee-win8
Huge version with GUI.  Features included (+) or not (-):
+acl             +clientserver    +cscope          -ebcdic          +float           +keymap          +menu            +netbeans_intg   +python/dyn      +smartindent     -tag_any_white   +vertsplit       +windows         
+arabic          +clipboard       +cursorbind      +emacs_tags      +folding         +langmap         +mksession       +ole             +python3/dyn     -sniff           -tcl             +virtualedit     +writebackup     
+autocmd         +cmdline_compl   +cursorshape     +eval            -footer          +libcall         +modify_fname    +path_extra      +quickfix        +startuptime     -tgetent         +visual          -xfontset        
+balloon_eval    +cmdline_hist    +dialog_con_gui  +ex_extra        +gettext/dyn     +linebreak       +mouse           -perl            +reltime         +statusline      -termresponse    +visualextra     -xim             
+browse          +cmdline_info    +diff            +extra_search    -hangul_input    +lispindent      +mouseshape      +persistent_undo +rightleft       -sun_workshop    +textobjects     +viminfo         -xterm_save      
++builtin_terms  +comments        +digraphs        +farsi           +iconv/dyn       +listcmds        +multi_byte      -postscript      -ruby            +syntax          +title           +vreplace        -xpm_w32         
+byte_offset     +conceal         -directx         +file_in_path    +insert_expand   +localmap        +multi_lang      +printer         +scrollbind      +tag_binary      +toolbar         +wildignore      
+cindent         +cryptv          -dnd             +find_in_path    +jumplist        +lua/dyn         -mzscheme        +profile         +signs           +tag_old_static  +user_commands   +wildmenu        
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$HOME\vimfiles\vimrc"
 3rd 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: "$HOME\vimfiles\gvimrc"
3rd 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=0x0400 -D_WIN32_WINNT=0x0400  /Fo.\ObjGOUYHAMD64/ /Ox -DNDEBUG  /Zl /MT -DFEAT_OLE -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_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python35.dll\" -DFEAT_HUGE /Fd.\ObjGOUYHAMD64/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib /machine:AMD64 gdi32.lib version.lib   winspool.lib comctl32.lib advapi32.lib shell32.lib  /machine:AMD64  libcmt.lib oleaut32.lib user32.lib   /nodefaultlib:lua52.lib   /nodefaultlib:python27.lib /nodefaultlib:python35.lib    WSock32.lib  /PDB:gvim.pdb -debug

[johnrichardrinehart]

@lervag, @Chiel92, I used that minimal vimrc file and that sample tex file and I was unable to reproduce the error. The only thing I changed was the value of let g:vimtex_view_general_viewer since SumatraPDF is on my path.

@Chiel92, can you add the directory containing SumatraPDF.exe to your PATH environment variable and change let g:vimtex_view_general_viewer = 'C:\\Program Files\\SumatraPDF\\SumatraPDF.exe' to let g:vimtex_view_general_viewer = 'SumatraPDF' and try again?

[chtenb]

Same error. It's probably not that the viewer can't be found, as the contents of that variable is checked for executability.

[chtenb]

Also, I tried setting varying the shellslash option to no avail.

[chtenb]

Does the error message make sense to either of you? I don't see any # symbol in the expression mentioned by the error.

[lervag]

The problem is that the # is expanded by vim to the alternate file. Could you try to add \s before the #s in line 174 of autoload/vimtex/compiler/latexmk.vim and test again?

As I've recently written to @fuzzybear3965 in a different thread, I really dislike working with issues related to Windows, because I don't use Windows myself and I am not able to find a perfect and reliable way to start the processes on Windows that works for everyone. As you see, your setup works for @fuzzybear3965. And I've tested vimtex on my windows machine and I don't have any problems. It seems there are some factors involved that I don't understand.

For instance, if my suggestion above should make things work for you, I already know that they will break things for other windows users. Thus I can't push that as a fix. However, if you or someone else can help me find the causes of why something works for someone and something else works for someone else, then we could probably improve the windows related code for everyone.

[lervag]

An obvious solution is to use Linux or OSX instead. (Sorry, I couldn't help myself...)

[chtenb]

That removes the error indeed. It now says compiler: started continuous mode. Nothing seems to be compiled though, and no viewer is started, but that might be me not understanding vimtex.

[chtenb]

For instance, if my suggestion above should make things work for you, I already know that they will break things for other windows users.

I understand. The correct solution would be to understand the cause of the difference in expansion, and write a check for that.

[lervag]

Exactly. However, as explained, I am not able to understand this cause. :(

I can't tell why a viewer is not started and why it seems that compilation is not really happening, even though it says compiler: started continuous mode. Things should work. Some pointers:

• Is SumatraPDF in your PATH, so that it opens? You can test from gvim with :!SumatraPDF.
• Try a simple example: First start compilation with \ll. Now check the folder: Does it generate new files? What happens if you type \lv (to start a viewer manually)?
• What is the output of \li after you have tried to start compilation?

[lervag]

Note: You can turn off callbacks with let g:vimtex_compiler_latexmk = {'callback' : 0}. This should disable the feature that involves the #s, and so things should work mostly as expected.

[chtenb]

There seems to be a conflict with other windows compatibility code that I have for other plugins. This code removes some folders from the PATH to make sure some wrong dlls are not accidentally loaded. (https://github.com/Valloric/YouCompleteMe/issues/1891)

The excluded folders in my case are.

C:\Python34\
C:\Program Files (x86)\Intel\iCLS Client\
C:\Program Files\Intel\iCLS Client\
C:\Windows\system32
C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86
C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64
C:\Program Files\Symantec.cloud\PlatformAgent\
C:\Program Files (x86)\CMake\bin
C:\Program Files (x86)\ChucK\bin

But the exclusion of system32 seems to break vimtex. The pragmatic fix is to use the following compatibility code. I'm sharing this in case other people use YCM or similar plugins in an environment similar to mine. The following code has to go at the top of your vimrc.

set nocompatible
let $PATH .= ';C:\Program Files\MiKTeX 2.9\miktex\bin\x64'
let $PATH .= ';C:\Strawberry\perl\bin'

if has("win32") && has("gui_running")
python << EOF
import os
import re
path = os.environ['PATH'].split(';')

def contains_msvcr_lib(folder):
    try:
        if 'system32' not in folder:
            for item in os.listdir(folder):
                if re.match(r'msvcr\d+\.dll', item):
                    return True
    except:
        pass
    return False

path = [folder for folder in path if not contains_msvcr_lib(folder)]
os.environ['PATH'] = ';'.join(path)
EOF
endif

This fixes the problem, and makes \ll and \lv work.

[chtenb]

This leaves us with the problem of detecting when escaping the # characters is necessary.

[lervag]

Great, that's useful to know. Thanks! And yes, it remains to understand the escaping issue.

Do you have access to more than one windows machine? It could be interesting to map up which Windows versions where vimtex works as expected. Although, in another issue it seemed that two "identical" windows installations showed different behaviour. Obviously, they were not identical, but I never understood what differed.

[chtenb]

No, this is my only windows box (work laptop). At home I use linux.

[lervag]

A quick question: Does it help to install a newer version of Vim? This should be readily available...

[lervag]

I've added test files for this now.

@Chiel92 Feel free to verify that my test files does reproduce the problem.

I've also added an info.md file to list the relevant info on which systems where things work and where they don't.

@fuzzybear3965 What are your system stats? I.e. which Windows version and which Vim version?

[johnrichardrinehart]

My main machine - my personal laptop - runs Windows 10 (ignoring the ever-evolving build number) with Vim 8.0.685.

My secondary system - my workplace desktop - is also a Windows 10 system with a synchronized gvim binary (that is, it should always be the same version as that on my laptop).

[lervag]

Thanks, @fuzzybear3965! Could you also provide the output of :version? I'm curious if the compiled in features may have something to do with things...

Btw: Did you experience different behaviour on personal laptop vs workplace desktop?

[johnrichardrinehart]

I tested on my workplace desktop: vimtex operates just fine. The major difference between the two machines is that the desktop has spaces in the home directory absolute path C:\Users\John Rinehart where my laptop doesn't (C:\Users\JohnRinehart). But, that shouldn't affect this problem.

I'm using gvim builds from tuxproject.de. Including my version info here is too bulky and GitHub-flavored Markdown doesn't parse the line breaks well (at all). You can find my version info here.

@Chiel92, could you try cloning my vimrc repository and using that with gvim -u vimrc/vimrc. You may need to create the directory C:\Users\YourUsernameHere\vimfiles and initialize the plugins (I use vim-plug) with :PlugInstall.

[chtenb]

@fuzzybear3965 What information could we draw from that? I reproduced the issue with a bare vimrc, with only vimtex installed.

[johnrichardrinehart]

Yeah, but your experience with a bare vimrc contradicted mine. I know you had already tried on your system with shellescape toggled, but I thought that there could possibly be some option enabled with my vimrc configuration that allows my compilation to succeed while yours fails.

But, I understand what you're saying. The problem seems to exist at a level below the vimrc configuration since I used your bare vimrc and managed successful compilations on both of my Windows 10 machines.

It was just something to try. I'm not sure why your case didn't work.

[lervag]

I recently started my windows laptop for a quick test for something else, but I made a note that I'm running Windows 10 Home edition with Vim 8. Can this be something related to the windows version?

[johnrichardrinehart]

I looked into this a bit and it doesn't seem that the command line parser has changed between Windows 7 and Windows 10. But, it's hard to find detailed changelogs regarding this. So, I'm mostly relying on the fact that no one has seemed to complain about the parser changing (no StackOverflow posts asking about spaces or backslashes or special characters in a command's name or arguments).

I'm having a really difficult time reproducing this issue. @Chiel92, if @lervag confirms a successful compilation given your mini vimrc and test file then we're kind of stuck without being able to determine exactly how your environment would produce results differently from ours. Do you have any ideas?

[lervag]

Huh, I found something interesting. If I start gvim from desktop icon or similar, or from command shell, then things work as expected. However, if I start gvim from Git shell, then I get an error from perl about the latexmk command and it does not compile. It is a different error than the one by @Chiel92, though.

[lervag]

Well, now I've spent some time on my windows machine, and except for observing different behaviour based on which shell starts the vim session, I am none the wiser. I really have no idea how to reliably solve this problem.

I think I might end up writing a notice for windows users that they use vimtex at their own risk. I don't really have the time to learn and understand how windows systems work to the point that I can solve this kind of issue.

I understand that this is annoying, and I wish I was able to be of more help. But for me, the conclusion is that I personally am not able to find a solution. This also means that for this issue to be solved, someone must be able to help me figure out what to do. Either one can change something on ones system so that vimtex works and this can be documented, or perhaps we can make changes to the vimtex code, but both require explicit suggestions either through a thread such as this or through PRs.

So, to conclude: I'll actually close this issue due to the above mentioned reasons. However, I will follow the discussions and if you think there might still be some hope, feel free to reopen.

[johnrichardrinehart]

@Chiel92, if you can, please continue to test this sporadically in the future to let us know if things change.

[chtenb]

Thanks for the effort so far. I understand it is hard to solve this if there is no clear reproduction scenario. If I learn anything else about this problem, I will post it here.

@lervag I use the "C:\Program Files\Vim\vim74\gvim.exe" executable by double clicking it (not by starting from a shell.

[lervag]

@Chiel92 Ok, thanks for the feedback. Double clicking is similar to what I do when things work. I think so, anyway.

[johnrichardrinehart]

@Chiel92 just to be clear for me and future readers: You navigate Windows Explorer to "C:\Program Files\Vim\vim74\gvim.exe" and double-click the executable? Or, am I misunderstanding, and you actually click a shortcut on the Desktop or you select the icon in the Start Menu or you select from the Context Menu in Windows Explorer (right-click menu)?

[chtenb]

yeah, the shortcut, but it points to that location

[johnrichardrinehart]

Okay. I only ask because, depending on the construction of the shortcut, the working directory of vim is potentially different than the location of vim.exe in the file system which can affect the runtime behavior of vim.