lervag / vimtex

VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
MIT License
5.52k stars 389 forks source link

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

Closed chtenb closed 7 years ago

chtenb commented 7 years ago

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 commented 7 years ago

Which version of Vim are you on?

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

chtenb commented 7 years ago
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 commented 7 years ago

@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 commented 7 years ago

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

chtenb commented 7 years ago

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

chtenb commented 7 years ago

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

lervag commented 7 years ago

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 commented 7 years ago

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

chtenb commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

lervag commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

lervag commented 7 years ago

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 commented 7 years ago

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

lervag commented 7 years ago

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

lervag commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

johnrichardrinehart commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

chtenb commented 7 years ago

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 commented 7 years ago

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

johnrichardrinehart commented 7 years ago

@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 commented 7 years ago

yeah, the shortcut, but it points to that location

johnrichardrinehart commented 7 years ago

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.