lervag / vimtex

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

Problem of Compilation for gvim on Windows #405

Closed hubanya closed 8 years ago

hubanya commented 8 years ago

First of all, thank you very much for this great vimtex.

I'm using it for gvim7.4 on Windows 10 and I always have problems in compiling my tex file when the tex file has errors. In this case, when I use <localleader>ll to start compiling, the command line displays "latexmk compile: started continuous mode" and lasts forever. Every time this occurs, I have to stop compiling using <localleader>lk, and run VimtexCompileSS! to see where the error is.

If my understanding of vimtex's documentation is correct, a QuickFix window is supposed to pop up when an error is encountered while compiling (at least in vimtex's default configuration). But this actually never happens to me.

When there is no error in my tex file, the continuous compilation works as expected.

Here is a minimal vimrc file I used:

set nocompatible
set guifont=Consolas:h12:cANSI

let &rtp  = '$Vim/vimfiles/bundle/vimtex,' . &rtp
let &rtp .= ',$Vim/vimfiles/bundle/vimtex/after'

filetype plugin indent on
syntax enable

let g:tex_flavor='latex'
let g:vimtex_view_general_viewer = 'SumatraPDF' 
let g:vimtex_view_general_options='-reuse-instance -forward-search @tex @line @pdf'
let g:vimtex_view_general_options_latexmk='-reuse-instance'

Here is a minimal tex file I used:

\documentclass{minimal}
\begin{document}
  $\alphb$
\end{document}

untitled

lervag commented 8 years ago

Do you have the clientserver feature in Vim? Please report the result of :echo has('clientserver'). It should return 1. If not, then this explains your issue and you should find another distribution of Vim on windows that has the clientserver compiled in.

To explain better: I think the compilation works as expected. The problem seems to be that the callbacks are not working, which means that you don't get feedback after compilation, and the quickfix window will not open. You can open the qf window with \le or :VimtexErrors; there is no need to do \lk and use VimtexCompileSS.

I don't really use windows myself, but I will try to help find and solve the problem.

hubanya commented 8 years ago

Thank you very much for your reply.

My gvim does indeed support clientserver. The command :echo has('clientserver') returns 1. Moreover, the quickfix window in fact will automatically pop up if there is no error but there is warning(s). See the following picture. I used the same minimal vimrc as I gave above. I just added \usepackage{caption2} in the test tex file to "trigger" the quickfix for warnings. Notice also there is no error in my tex file.

untitled

Therefore, callbacks should have correctly worked when there are only warnings but no errors.

Moreover, you have suggested to open quickfix window with \le or :VimtexErros. But I only got message

latexmk errors: No errors!

Then I directly edit my minimal tex file to correct the error (I know what the error is because I created it in the above minimal tex file) and then use :w to save. I got the message

E505: "Desktop\test\test.tex" is read-only (add ! to override)

I don't know what's happening and I really appreciate if you can help. Thank you very much!

lervag commented 8 years ago

Hmm, ok. Could you start from a minimal document with no errors:

  1. Start compilation
  2. Add some text (no errors)
  3. Does it now compile automatically? Does it say latexmk compile: success after compilation inside Vim?
  4. Now add an error and save the file.
  5. Does the quickfix window open this time?
johnrichardrinehart commented 8 years ago

@hubanya, At the risk of stepping on @lervag's toes, can you try installing Strawberry Perl (32-bit or 64-bit) and adding it to your PATH? Some users have experienced similar issues and this seems to be mitigated by a different perl executable. See #378 and #297 for reports of similar problems.

hubanya commented 8 years ago

Thank you again for your reply.

Here are the steps and results:

  1. Start with a minimal tex file without any error.
  2. Use \ll to compile for the first time. It says latexmk compile: started continuous mode and then latexmk compil: success. At the same time SumatraPDF launches and shows the output PDF (perhaps this is not relevant for compilation)
  3. Add some new texts to the tex file and save :w. After a few seconds, gvim says latexmk compile: success again. Check PDF, it shows the newly added texts.
  4. Add an error $\alphab$ to the tex file and save :w. Nothing happens.
  5. Correct the tex file: change $\alphb$ to $\alpha$ and save :w, it says E505: "Desktop\test\test.tex" is read-only (add ! to overide).
hubanya commented 8 years ago

@fuzzybear3965 Thank you very much for your help. In fact I have already installed Strawberry Perl and it is included already in $PATH. Do you have a second thought?

johnrichardrinehart commented 8 years ago

@hubanya, your problem does not sound related to the issues I referenced. Edit: You have already installed perl so that wouldn't be the issue.

What is the output of :let g:vimtex_quickfix_mode?

hubanya commented 8 years ago

@fuzzybear3965 Thanks again. :let g:vimtex_quickfix_mode shows 2.

johnrichardrinehart commented 8 years ago

@hubanya, while I have you: What is the output of the following:

  1. :let g:vimtex_latexmk_callback
  2. g:vimtex_latexmk_continuous
  3. :VimtexInfo (after you have started the compilation process at least once with an open buffer)

Also, in the Windows Task Manager can you see latexmk and perl active when you start compiling? Can you see those two processes terminate when you stop compiling?

hubanya commented 8 years ago

@fuzzybear3965 Thank you!

  1. :let g:vimtex_latexmk_callback shows #1
  2. let g:vimtex_latexmk_continuous shows #1
  3. :VimtexInfo: it seems I can not copy what it shows. Is there any way I can copy that? If not, I will type them here.

Now, here is what happens in Task Manager.

  1. Before any compilation, neither latexmk.exe nor perl.exe appears.
  2. After I compile a correct tex file, using \ll, both latexmk.exe and perl.exe appear.
  3. Now I change the tex file and create some errors like $\alphb$, both latexmk.exe and perl.exe remain. In addition, pdflatex.exe which did not show up in step 2 also appears.

The following is the output \lo when there is an error:

Latexmk: applying rule 'pdflatex'... This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/W32TeX) (preloaded format=pdflatex) restricted \write18 enabled. entering extended mode (./test.tex LaTeX2e <2016/02/01> Babel <3.9q> and hyphenation patterns for 81 language(s) loaded. (c:/texlive/2015/texmf-dist/tex/latex/base/minimal.cls Document Class: minimal 2001/05/25 Standard LaTeX minimal class ) (./test.aux) ./test.tex:4: Undefined control sequence.

\alphb l.4 $\alphb $ ?
johnrichardrinehart commented 8 years ago

@hubanya, to capture the output from :VimtexInfo you can use the following sequence: :redir @+, :VimtexInfo, :redir end. redir @+ will redirect the output to the + register (system clipboard) and then redir end will stop this redirection. You can then Ctrlv the output to the GitHub comment.

I can't reproduce the behavior of your error. pdflatex.exe is never spawned as its own process as far as I can tell. Does pdflatex.exe stay alive for as long as you have continuous compilation enabled?

Also, go through @lervag`s post and give us that, too. The more information, the better!

Can you try using the vimtex.vimrc file that is located in my repository? I know that that works.

lervag commented 8 years ago

I think perhaps the problem is related to this: "In addition, pdflatex.exe which did not show up in step 2 also appears."

Do you have a latexmkrc file?

hubanya commented 8 years ago

@lervag Thank you!

Yes, I had a latexmkrc file. It only contains one line:

$pdflatex = 'pdflatex -synctex=1 %O %S';

I copied this line from vimtex documentation for forward/backward search.

The problem is even if I completely remove latexmkrc file, the above problem remains. In fact, in all above minimal tests, I have already removed this file.

But I think you are right, the problem might just be the pdflatex.exe in my Task Manager. If I end this task in Task Manager while gvim shows latexmk compile: started continuous mode for an erroneous texfile , the gvim will immediately show latexmk compile: failure, but no quickfix window pops up. In this case, if I use \le to check for errors, it says vimtex errors: No errors!

hubanya commented 8 years ago

@fuzzybear3965 Thank you very much for letting me know the redir trick!

Here is what I copied:

b:vimtex : test pid : 4352 out : '' tmp : 'C:\Users\huban\AppData\Local\Temp\VIA3536.tmp' root : 'C:\Users\huban\Desktop\test' aux : 'C:\Users\huban\Desktop\test/test.aux' log : 'C:\Users\huban\Desktop\test/test.log' tex : 'C:\Users\huban\Desktop\test\test.tex' cmd_latexmk_compile : 'cmd /s /c "cd /D "C:\Users\huban\Desktop\test" && set max_print_line=2000 & latexmk -verbose -pdf -e "$pdflatex =~ s/ / -file-line-error /" -pvc -e "$success_cmd = ''\"C:\Apps\Vim\vim74\gvim.exe\" --servername GVIM --remote-expr \"vimtex#latexmk#callback(1)\"''" -e "$failure_cmd = ''\"C:\Apps\Vim\vim74\gvim.exe\" --servername GVIM --remote-expr \"vimtex#latexmk#callback(0)\"''" -e "$pdf_previewer = ''SumatraPDF -reuse-instance''" "test.tex" >C:\Users\huban\AppData\Local\Temp\VIA3536.tmp"' base : 'test.tex'

viewer init : function('28') view : function('29') latexmk_append_argument : function('30')

For @lervag 's post, please see my answer here.

hubanya commented 8 years ago

@fuzzybear3965 I tried your vimrc file and I notice if add --interaction=nonstopmode, then compilation becomes as expected! That is, I added one line in my _vimrc file

let g:vimtex_latexmk_options='-pdflatex="pdflatex --interaction=nonstopmode"', then the quickfix indeed pops up, indicating the error! You are the man! If I correct the error in my tex file and save :w, then it automatically compile again and says latexmk compile: success. I think this is what continuous mode is supposed to do! Thank you!

But here is one problem. After the quickfix windows launches, If I use either :cn or :cp to jump between errors in my tex, all the texts in my tex file suddenly disappears. Do you know what the problem is?

1

Use :cn command 2

johnrichardrinehart commented 8 years ago

I have no idea why this would be happening and I can not reproduce that error with my configuration. Do me a favor and comment out your entire vimtex.vimrc file (or equivalent) and paste mine into yours. Also, make sure that you don't have some strange :imap or :nmap that would be causing this error.

hubanya commented 8 years ago

@fuzzybear3965

Let me reproduce this in the following.

The first is my entire minimal vimrc file. Notice I completely copied your configuration and uncommented the line let g:vimtex_latexmk_options.

set nocompatible
let &rtp  = 'C:\Apps\Vim\vimfiles\bundle\vimtex,' . &rtp
filetype plugin indent on
syntax enable

" Copied from fuzzybear3965
nmap <F9> <plug>(vimtex-compile-toggle)
" let g:vimtex_mapping_enabled = 0
let g:vimtex_imaps_leader = '@'
let g:vimtex_fold_enabled = 0
let g:vimtex_latexmk_progname='gvim'
let g:vimtex_view_general_viewer = 'SumatraPDF'
" Below, I had to remove the recorder option because Perl for Windows has
" trouble with this
let g:vimtex_latexmk_options='-recorder- -pdflatex="lualatex --shell-escape --interaction=nonstopmode"'
" let g:vimtex_latexmk_options='-pdf
"let g:vimtex_delim_toggle_mod_list = [
"         \ ['\left', '\right'],
"         \ ['\bigl', '\bigr'],
"         \ ['\Bigl', '\Bigr'],
"         \ ['\biggl', '\biggr'],
"         \ ['\Biggl', '\Biggr'],
"         \ ['\big', '\big'],
"         \ ['\Big', '\Big'],
"         \ ['\bigg', '\bigg'],
"         \ ['\Bigg', '\Bigg'],
"         \]

Second is my test tex file

\documentclass{minimal}
\begin{document}
  $\alphb$

  $\bett$
\end{document}

Leave the cursor at the very beginning of the above tex file. Press <F9> to start compiling. The QuickFix window pops up, showing two errors.

.\test.tex|3 error| Undefined control sequence. .\test.tex|5 error| Undefined control sequence.

The first error is highlighted with yellow background. The cursor remains at the very beginning of the tex file. Now jump to the second error :cn. Suddenly all texts in tex file disappear.

Now I understand why this happens. Actually, when I use :cn, gvim starts a new buffer! When the quickfix window pops up, here is the output of :ls

1 %a "Desktop\test\test.tex" line 1 3 a- "[Quickfix List]" line 0

After I use :cn, the :ls output becomes

1 # "Desktop\test\test.tex" line 1 2 %a ".\test.tex" line 1 3 a- "[Quickfix List]" line 0

I guess the problem comes from the quickfix window messages above. It says .\test.tex at the beginning.

hubanya commented 8 years ago

@fuzzybear3965 Here is an update for the above post

Whether the quickfix jumps to the correct line or open a new buffer depends on whether it shows test.tex or .\test.tex, where test.tex is the file name in c:\users\huban\Desktop\test\. If it is the former, it jumps to the correct line. If it is the latter, it opens a new buffer called .\test.tex.

Wrong file name in quickfix

1 .\test.tex|3 error| Undefined control sequence. 2 .\test.tex|5 error| Undefined control sequence.

Correct file name in quickfix

1 test.tex|3 error| Undefined control sequence. 2 test.tex|5 error| Undefined control sequence.

Moreover, whether it correctly shows test.tex or .\test.tex depends on how I open gvim and the file. Here are four methods I have tried and they gave me different results.

  1. From Windows cmd, use command gvim c:\users\huban\Desktop\test\test.tex, it shows test.tex in quickfix and thus jumps correctly.
  2. In Windows, go to the directory c:\users\huban\Desktop\test\ in My Computer, right-click on the file test.tex and choose Edit with gvim. It is correct too as in 1.
  3. Open gvim first, click File and then Open. It is not correct, i.e. it shows .\test.tex in qf and does not jump correctly.
  4. Open gvim first, open the tex file using :e command. It is not correct as in 3.

Do you have any idea about why this happens? @lervag

Thank you!

johnrichardrinehart commented 8 years ago

@hubanya, this is great information! I feel that we're close! For each of the above tests, can you please tell me the output of :echo @%'? This will tell me whatgvim` has determined to be the name of the file in each case.

hubanya commented 8 years ago

@fuzzybear3965 Thank you!

When it is correct, 1&2, it shows test.tex. When it is not correct, 3&4, it shows Desktop\test\test.tex.

johnrichardrinehart commented 8 years ago

Okay, this is making sense. @hubanya, when shortcuts to applications are made on Windows they have a couple paths associated with them. One of those paths is the executable location. This is known as the Target: directory (in this case, this is wherever you have gvim.exe installed - probably something like C:\Program Files (x86)\vim\vim74. The other path (the Start in: path) is the directory in which the executable is to start. That is, the Start In: path is defined as the current working directory of the application. You can see both of these by right-clicking the shortcut and viewing its properties.

My guess is that launching gvim from the context menu (right-click menu), case 3, and start menu, case 4, (I'm assuming that in 4 you are using the start menu or some other shortcut to launch gvim) sets the current directory gvim to C:\Users\huban because of the way the application shortcut is generated by the vim installer. This would make the path of the current file Desktop\test\test.tex relative to the starting directory, which would be C:\Users\huban. Add the following to your vimrc , then :source $MYVIMRC, and try 1-4 again. Let me know what happens.

set autochdir.

Also, for my knowledge, open up an instance of Windows Explorer (file system navigator) and, in the location/URL bar in the top, paste in %appdata% and press Return/Enter. You should be in a directory resembling C:\Users\huban\AppData\Roaming. From there, navigate to Microsoft\Windows\Start Menu and look for the gvim shortcut underneath that branch of the filesystem tree (if it's not in Start Menu it might be in Programs immediately below it). Right-click that icon, if you find it, and tell me what's recorded in the Start in: field. Let me know if this is, indeed, C:\Users\huban.

@lervag, This seems to be a problem with how vimtex identifies the current file name. I think this is worthy of an edit. Let me know what you think.

lervag commented 8 years ago

First, regarding the main issue: I've added the option to the automatic options, so now you shouldn't need the option in your vimrc file for things to work. Please test.

Second, regarding the problem with navigating the quickfix list: Please try with the option let g:vimtex_quickfix_fix_paths = 1.

johnrichardrinehart commented 8 years ago

Okay. I have removed interaction=nonstopmode from my vimrc file. Compilation works as expected. I hadn't seen that options since you added it with 5771ed00aa532be1f16ca4d0223c7175863403e5. I'm sorry about that. I would have recommended it, myself, otherwise.

hubanya commented 8 years ago

@lervag Thank you very much! Now compilation works as expected: errors automatically trigger quickfix. But let g:vimtex_quickfix_fix_paths=1 does not work as expected. The same problem remains. @fuzzybear3965 's suggestion of adding set autochdir to vimrc in post actually works.

Here is my minimal vimrc when test let g:vimtex_quickfix_fix_paths=1:

set nocompatible
let &rtp='c:\apps\vim\vimfiles\bundle\vimtex,'. &rtp
filetype plugin indent on    
set guifont=Powerline_Consolas:h12:cANSI
let g:tex_flavor='latex'
let g:vimtex_view_general_viewer = 'SumatraPDF' 
let g:vimtex_view_general_options='-reuse-instance -forward-search @tex @line @pdf'
let g:vimtex_view_general_options_latexmk='-reuse-instance'
let g:vimtex_latexmk_progname = "gvim"
let g:vimtex_quickfix_fix_paths=1

If I add set autochdir to the above vimrc file, then the quickfix identifies the file directory correctly.

lervag commented 8 years ago

Strange. @hubanya, could you add echom 'test' to the top of the function s:fix_quickfix_paths() in autoload/vimtex/latexmk.vim. Now, with your minimal vimrc file, open the tex file and do \le to open the quickfix window. Check your messages :messages, did it print "test" ?

hubanya commented 8 years ago

Moreover, if I understand ba75606 correctly, if I want forward/backward search, I still have to use

let g:vimtex_latexmk_options='-pdflatex="pdflatex -synctex=1 -interaction=nonstopmode %O %S"'

So -interaction=nonstopmode is still needed because later option will dominate previous option in latexmk.

Moreover adding $pdflatex='pdflatex -synctex=1 %O %S'; to .latexmkrc file and leave g:vimtex_latexmk_options as default value will not work for forward/backward search because rc file is read first and so is overridden by later -pdflatex in ba75606.

Therefore I guess we need a better way to adding the option -interaction=nonstopmode than its new implementation.

lervag commented 8 years ago

I could just add synctex=1 as well...?

Or I could add a faq about compilation seemingly stopping, where I can explain that one need these options?

hubanya commented 8 years ago

@lervag Personally I think the second method is better. Just leave the code as it was (without the new patch) but in doc, explain briefly how to use g:vimtex_latexmk_options. Because by doing this, people can use complicated configurations for -pdflatex by using latexmkrc.

Of course this is just my own opinion:)

lervag commented 8 years ago

I agree. To make it more clear for when I get the time to update the docs, I'll open a new issue. Hope that's ok.

johnrichardrinehart commented 8 years ago

If a compromise is desired, two new variables, like g:vimtex_latexmk_pdflatex_synctex_enable and g:vimtex_latexmk_pdflatex_interaction_nonstopmode, can be added that are set to defaults based on the operating system inolved (in plugin source, if has("win32") ... elif has("unix") endif). That would seem to mitigate this issue while allowing for full control of the g:vimtex_latexmk_options option.

hubanya commented 8 years ago

@lervag About you post. Yes, :messages prints

"Desktop\test\test.tex" 10L, 99C test "C:\Apps\Vim_vimrc" 11L, 429C

In my minimal vimrc, let g:vimtex_quickfix_fix_paths=1.

Thanks.

lervag commented 8 years ago

@fuzzybear3965 Thanks for the suggestion. However, I don't want to add more options, unless it is really necessary. In this case, I would say it isn't.

@hubanya Good, that means that the autocommand is fired. The function I mentioned should update the paths to be relative to your current directory. Could you try the following update to the function:

  let qflist = getqflist()
  echom s:vimtex_tmp_path
  for i in qflist
    let file = s:vimtex_tmp_path . '/'
          \ . substitute(bufname(i.bufnr), '^\.\/', '', '')
    echom file
    if !bufexists(file) && filereadable(fnameescape(file))
      echom 'yes' fnamemodify(file, ':~:.')
      execute 'badd' fnamemodify(file, ':~:.')
    else
      echom 'no' !bufexists(file) filereadable(fnameescape(file))
    endif
    let i.bufnr = bufnr(file)
    echom i.bufnr
  endfor
  call setqflist(qflist)

This should write some informative messages that will help understand why it doesn't work.

hubanya commented 8 years ago

Here are the results. First \ll to start continuous compilation for a tex file that contains errors. The quickfix window pops up. Now :message shows

"Desktop\test\test.tex" 10L, 99C test C:\Users\huban\Desktop\test

Then Use \le to close quickfix and \le again to open quickfix. Then :messages shows

"Desktop\test\test.tex" 10L, 99C test C:\Users\huban\Desktop\test C:\Users\huban\Desktop\test C:\Users\huban\Desktop\test/.\test.tex no 0 1 1 C:\Users\huban\Desktop\test/.\test.tex no 0 1 1

Moreover, I also tried launching gvim c:\Users\huban\Desktop\test\test.tex from cmd because I know the jump in quickfix will work in this way. Here are the corresponding messages

"~\Desktop\test\test.tex" 10L, 99C test c:\users\huban\Desktop\test c:\users\huban\Desktop\test c:\users\huban\Desktop\test/test.tex no 0 1 1 c:\users\huban\Desktop\test/test.tex no 0 1 1

Thank you!

lervag commented 8 years ago

It seems the problem is related to the slashes... I'll try to find a way to solve it.

lervag commented 8 years ago

Ok, the problem is probably that I explicitly use the / when composing the paths. Try to change the slash to a backslash and check if it works. I.e., do this change:

-let file = s:vimtex_tmp_path . '/'
+let file = s:vimtex_tmp_path . '\'
Rmano commented 8 years ago

...hmmm... shouldn't you escape the backslash? Or the single quotes took care of that?

hubanya commented 8 years ago

@lervag I got no luck by using backslash \.

Here is the :messages

"Desktop\test\test.tex" 8L, 91C test C:\Users\huban\Desktop\test C:\Users\huban\Desktop\test .\test.tex C:\Users\huban\Desktop\test.\test.tex no 0 1 1 .\test.tex C:\Users\huban\Desktop\test.\test.tex no 0 1 1

I even changed the string ^\.\/ in the substitute function to ^\.\\, and no luck. Here is :messages

"Desktop\test\test.tex" 8L, 91C test C:\Users\huban\Desktop\test C:\Users\huban\Desktop\test .\test.tex C:\Users\huban\Desktop\test\test.tex no 0 1 1 .\test.tex C:\Users\huban\Desktop\test\test.tex no 0 1 1

After the quickfix window pops up, I checked :echo getqflist:

[{'lnum': 3, 'bufnr': 2, 'col': 0, 'valid': 1, 'vcol': 0, 'nr': -1, 'type': 'E', 'pattern': '', 'text': 'Undefined control sequence.'}, {'lnum': 5, 'bufnr': 2, 'col': 0, 'valid': 1, 'vcol': 0, 'nr': -1, 'type': 'E', 'pattern': '', 'text': 'Undefined control sequence.'}] The bufnr changed to 2. I don't know why this happens and if this can help.

johnrichardrinehart commented 8 years ago

Okay, so I've spent some time analyzing this issue. In case these things aren't already known, let me identify some of the issues that I see.

A cd command to the directory in which the file is located is performed prior to compilation. This has the effect of making the log file record the current directory of the file as '.' instead of the path that is relative to the working directory, as it should be. So, when the quickfix list is populated, every file is assumed to be in the working directory (which is why autochdir works so well). Now, if one were to remove the cd command from the cmd_latexmk_compile string, then one would need to pass the directory of the file relative to the working directory. This seems like the best way to do things. This would make the quickfix window "see" the right paths relative to getcwd().

So, it seems that in order to fix this issue some changes have to be made to s:latexmk_build_cmd(). It seems to me that the compilation should always be started from the working directory and that the -output-directory option should always be used to place auxiliary and compiled files in the right location. Thus, I think the inclusion of cd to the directory of the file being compiled is a mistake. Correct me if I'm wrong.

I can take some time to try to fix this issue, myself, later this week. However, I worry that my "fix" will introduce more problems. It would be my first pull request ever and not in my strongest language (I barely know any VimScript). But, I'll give it a go. @lervag, don't let this stop you from trying to fix it before me.

@hubanya, for the interim, I would suggest adding set autochdir to your vimrc file, for now.

hubanya commented 8 years ago

@fuzzybear3965 Thank you very much. I'm sorry that I can not help you in terms of the code. But I'm willing to do various tests you want when you make any progress.

lervag commented 8 years ago

@fuzzybear3965 Perhaps you are right. If so, then this actually simplifies things quite a lot. However, there are quite a few things that can go wrong, so it will require a lot of testing. Also, the clean commands use the same technique as the current one (with cd). I will appreciate your contribution, and if you open a pull request, we can work on it together. In any case, feel free to try! I've made an initial attempt, see here:

:!git --no-pager diff
diff --git a/autoload/vimtex/latexmk.vim b/autoload/vimtex/latexmk.vim
index 5c9b2fe..f1c16d8 100644
--- a/autoload/vimtex/latexmk.vim
+++ b/autoload/vimtex/latexmk.vim
@@ -398,16 +398,14 @@ function! s:latexmk_build_cmd() " {{{1
   let tmp = tempname()

   if has('win32')
-    let cmd  = 'cd /D "' . b:vimtex.root . '"'
-    let cmd .= ' && set max_print_line=2000 & latexmk'
+    let cmd = 'set max_print_line=2000 & latexmk'
   else
-    let cmd  = 'cd ' . vimtex#util#shellescape(b:vimtex.root)
     if fnamemodify(&shell, ':t') ==# 'fish'
-      let cmd .= '; and set max_print_line 2000; and latexmk'
+      let cmd = 'set max_print_line 2000; and latexmk'
     elseif fnamemodify(&shell, ':t') ==# 'tcsh'
-      let cmd .= ' && set max_print_line=2000 && latexmk'
+      let cmd = 'set max_print_line=2000 && latexmk'
     else
-      let cmd .= ' && max_print_line=2000 latexmk'
+      let cmd = 'max_print_line=2000 latexmk'
     endif
   endif

@@ -418,9 +416,8 @@ function! s:latexmk_build_cmd() " {{{1
           \ '$pdflatex =~ s/ / -file-line-error /')
   endif

-  if g:vimtex_latexmk_build_dir !=# ''
-    let cmd .= ' -outdir=' . g:vimtex_latexmk_build_dir
-  endif
+  let cmd .= ' -outdir=' . get(g:, 'vimtex_latexmk_build_dir',
+        \ vimtex#util#shellescape(b:vimtex.root))

   if g:vimtex_latexmk_continuous
     let cmd .= ' -pvc'
@@ -446,7 +443,7 @@ function! s:latexmk_build_cmd() " {{{1
     let cmd .= b:vimtex.viewer.latexmk_append_argument()
   endif

-  let cmd .= ' ' . vimtex#util#shellescape(b:vimtex.base)
+  let cmd .= ' ' . vimtex#util#shellescape(b:vimtex.tex)

   if g:vimtex_latexmk_continuous || g:vimtex_latexmk_background
     if has('win32')

@hubanya In the meantime, I think @fuzzybear3965 is right to suggest using set autochdir, although this should not be necessary when we get things right. Please also feel free to test some variations on the backslash as I proposed. I think it should be possible to find a good solution without the update proposed by @fuzzybear3965, but since I don't sit on a windows box, it is difficult for me to experiment and find the correct syntax..

johnrichardrinehart commented 8 years ago

I will try this later today. I have a heavy workload for this week, but I am looking forward to having this issue resolved.

lervag commented 8 years ago

Great! By the way, does the option shellslash help here? @hubanya That is, does the quickfix fix paths stuff work if you add set shellslash to your vimrc file?

hubanya commented 8 years ago

Thank you for your efforts.

I have tested set shellslash, but got no luck on the original scripts.

I will try your post.

hubanya commented 8 years ago

I have tried post and it does not work, with or without set shellslash. In fact, no errors are caught by vim. Output of \le is nothing. Even my directory containing the tex file has nothing after compiling, no aux, no log.

Here is \li message:

b:vimtex : test pid : 8108 out : '' aux : '' log : '' tmp : 'C:/Users/huban/AppData/Local/Temp/VIABC07.tmp' root : 'C:/Users/huban/Desktop/test' tex : 'C:/Users/huban/Desktop/test/test.tex' cmd_latexmk_compile : 'cmd /s /c "set max_print_line=2000 & latexmk -verbose -pdf -e "$pdflatex =~ s/ / -file-line-error /" -outdir= -pvc -e "$success_cmd = ''\"C:\Apps\Vim\vim74\gvim.exe\" --servername GVIM --remote-expr \"vimtex#latexmk#callback(1)\"''" -e "$failure_cmd = ''\"C:\Apps\Vim\vim74\gvim.exe\" --servername GVIM --remote-expr \"vimtex#latexmk#callback(0)\"''" -e "$pdf_previewer = ''SumatraPDF -reuse-instance''" "C:/Users/huban/Desktop/test/test.tex" >C:/Users/huban/AppData/Local/Temp/VIABC07.tmp"' base : 'test.tex'

viewer init : function('17') view : function('18') latexmk_append_argument : function('19')

johnrichardrinehart commented 8 years ago

@hubanya, I can confirm that with set shellslash and with the edits recommended by @lervag, above, that compilation never starts (no latexmk process is ever started). Below is the cmd_latexmk_compile in this circumstance.

cmd_latexmk_compile : 'cmd /s /c "set max_print_line=2000 & latexmk -verbose -pdf  -e "$pdflatex =~ s/ / -file-line-error /" -outdir= -pvc -e "$success_cmd = ''''""''C:\Program Files (x86)\vim\gvim.exe''""'' --servername GVIM --remote-expr \"vimtex\#latexmk\#callback(1)\"''" -e "$failure_cmd = ''''""''C:\Program Files (x86)\vim\gvim.exe''""'' --servername GVIM --remote-expr \"vimtex\#latexmk\#callback(0)\"''" -e "$pdf_previewer = ''SumatraPDF''" "C:/Users/John Rinehart/Desktop/test.tex" >C:/Users/JOHNRI~1/AppData/Local/Temp/VIBFF44.tmp"'

However, with set noshellslash and using the above recommended changes, compilation does start and finish and the callbacks are executed just fine. However, we still have the quickfix path issue. Below is the cmd_latexmk_compile for this circumstance. I pulled the most recent commit, 74979580a211133cc4cfaf3fea, before implementing these recommended changes.

  cmd_latexmk_compile : 'cmd /s /c "set max_print_line=2000 & latexmk -verbose -pdf  -e "$pdflatex =~ s/ / -file-line-error /" -outdir= -pvc -e "$success_cmd = ''""""""C:\Program Files (x86)\vim\gvim.exe"""""" --servername GVIM --remote-expr \"vimtex\#latexmk\#callback(1)\"''" -e "$failure_cmd = ''""""""C:\Program Files (x86)\vim\gvim.exe"""""" --servername GVIM --remote-expr \"vimtex\#latexmk\#callback(0)\"''" -e "$pdf_previewer = ''SumatraPDF''" "C:\\Users\\John Rinehart\\Desktop\\test.tex" >C:\Users\JOHNRI~1\AppData\Local\Temp\VIC8EA8.tmp"'

The value for base was test.tex for each case. That seems to be what it should be. I don't think that value should include the path to the test.tex file from the working directory.

I'm going to make some time to look at this in a couple days, in earnest. I hope to have a pull request for at least the compilation. The latexmk clean command should be similar.

lervag commented 8 years ago

@fuzzybear3965 and @hubanya Just to be clear, my earlier mentioned edits were not really expected to solve anything. They were simply a start on the idea of @fuzzybear3965 to stop using cd at the beginning of the latexmk command.

Right now I am a little bit confused about what are the issues. Am I correct that there is only one issue here now: That the quickfix entries are not correct unless one has set autochdir? If so, perhaps one could open a new issue about this with a simple and clear description? That would help me a lot, since I don't have that much time, and reading these long threads is time consuming.

hubanya commented 8 years ago

Ok, I open a new issue #421.

Thanks.

lervag commented 8 years ago

Thanks you too! Unless I am mistaken, we can leave this issue as resolved and continue the discussion about the quickfix entries in the new issue.

johnrichardrinehart commented 8 years ago

Yes, this is good. Leave this issue closed. We will resume discussion in #421.