Closed Th3Tr00p3r closed 3 years ago
Yes, this seems related to a recent PR: #2076. See also #2078, then #2079. Perhaps I could ask for input/assistance from @Nicholas42 (although I understand he does not use Windows) and @yongrenjie. As I don't use Windows myself, I find it hard to address such issues.
One idea, @Nicholas42: We could revert your contribution on Windows only and keep it for unixes?
Disabling it is the only thing I can do. It is surely some problem with windows command line escaping but I have no idea at all how to fix it and cannot test it. Added this in #2085.
@Th3Tr00p3r If you want you can play a bit around with this line:
and find out out what is the problem. It should be at this point but I don't know what it is.
Hey guys, thank you so much for addressing this so quickly, and sorry for not returning the favor, I just posted this issue and went to sleep...
Using the latexmk.vim file from the commit @Nicholas42 suggested solved it for me.
Thanks a lot! I'll force myself not to upgrade the plugin for now...
@Th3Tr00p3r: I can try to investigate this, but as of now I cannot reproduce it with a blank vimrc on gvim 8.2 / Win 10, and with this tex file:
\documentclass{article}
\begin{document}
Hi
\end{document}
Could you also specify: (1) what vimtex-related config (if any) do you have in your vimrc or .vim/ftplugin/tex.vim
files? and (2) do you have a minimal tex file for which this happens?
I'm implicitly assuming that gvim/nvim isn't the issue, but could look into that later...
Oh dear, apparently it is an nvim issue. I can reproduce it with nvim, but not on gvim.
Can you reproduce this on the latest nightly, then? (I use vimtex
with \ll
on neovim under macOS without any issues.)
Yup, it's reproducible with the same file above on both 0.4.4 and nightly (v0.5.0-dev+1459-g384f9870f
).
This one is a Windows-only issue. I just tested with nvim on my Mac and that's fine too (although I use vim8 myself).
I see. The jobs implementation is slightly different, and Windows is always tricky -- I don't use it myself, so I can't help unfortunately.
This function is used to build the commandline for running latexmk. Could someone post these commandlines on windows for both vim and nvim? It seems like this could be an nvim bug.
@Nicholas42 Disabling it is the only thing I can do. It is surely some problem with windows command line escaping but I have no idea at all how to fix it and cannot test it. Added this in #2085.
@Th3Tr00p3r Using the latexmk.vim file from the commit @Nicholas42 suggested solved it for me.
Thanks! I'm merging the PR asap as I believe it is more important that things generally work as expected. If we find a solution we can implement it afterwards.
@yongrenjie Oh dear, apparently it is an nvim issue. I can reproduce it with nvim, but not on gvim.
Thanks for investigating! The difference between neovim and Vim is the backend used for running the commands (jobstart
in neovim and job_start
in Vim; these behave and are implemented differently!). But VimTeX passes the same command string to the job backend in both cases:
I believe the difference may be in how the shell command is executed. It seems job_start
in Vim does not run the command through the shell, whereas neovim with jobstart
uses the shell if the argument is a string (see the first lines of :help jobstart
). However, and again, I don't use Windows and can't really do any real testing here. So I'll leave it at this. If anyone do look into these things further and find good ideas of improving VimTeX for Windows, it will be appreciated!
I think I've figured out the fix. I can't admit I know exactly why, but I assume it must be related to some sort of shell escaping, based on what @lervag mentioned above. With nvim the &
symbol used in the perl command needs to be escaped (by preceding it with a caret ^
), so the following works (tested on nvim 0.5.0, 0.4.4, and gvim 8.2 on Win10, with and without an existing $success_cmd
). Obviously, this can be refactored, but I'll leave it to @Nicholas42
function! s:wrap_option_appendcmd(name, value) abort " {{{1
if has('win32') && has('nvim')
return ' -e "$' . a:name . ' = ($' . a:name . ' ? $' . a:name . ' . '' ^& '' : '''') . ''' . a:value . '''"'
elseif has('win32')
return ' -e "$' . a:name . ' = ($' . a:name . ' ? $' . a:name . ' . '' & '' : '''') . ''' . a:value . '''"'
else
return ' -e ''$' . a:name . ' = ($' . a:name . ' ? $' . a:name . ' . " ; " : "") . "' . a:value . '"'''
endif
endfunction
Ah, nice, thanks a lot! Have you tried the version with the caret on gvim? If that also works, it would be the most elegant thing to always have the escaping.
Yup, I did, but it didn't quite work correctly. I think it's over-escaping, which causes the original $success_cmd
to be run with an extra parameter & echo 'vimtex_compiler...'
.
Thanks! I'll merge this asap. @Th3Tr00p3r, can you fetch the latest master and see if things still work as expected after the fix?
I upgraded via vim-plug and everything seems to be working fine. Thanks again.
Glad to hear it!
Hello, I have this weird issue that has just popped out seemingly out of nowhere - I'm saying this since vimtex has worked for me in the past few days, compiling without issues using
\ll
. Now for some reason, when I do\ll
a buffer opens showing the following::VimtexInfo
yields:Any ideas I can test? Thanks.