Error starting latexmk

[Rmano]

Hi --- I have tried to switch form latex-box to vim-latex due to LaTeX-Box-Team/LaTeX-Box#220

I have a problem though. With the default settings, when I try to start compilation (\ll) I have the following error:

Error detected while processing function latex#latexmk#toggle..latex#latexmk#com
pile..<SNR>45_latexmk_set_cmd:
line   20:
E121: Undefined variable: v:progpath
E15: Invalid expression: v:progpath
line   21:
E121: Undefined variable: callback
line   22:
E121: Undefined variable: callback
line   27:
E121: Undefined variable: callback
E15: Invalid expression: ' -e ''$success_cmd .= "' . callback . '"''' .  ' -e ''
$failure_cmd .= "' . callback . '"'''
latexmk continuous mode started successfully
Press ENTER or type command to continue

...and then it seems to work, but if I have an error in the document the quickfix window does not appear and the file is not updated (silently).

Thank for your plugin!

[lervag]

Ah, I recently made a small update due to a tip about the variable v:progpath. I thought this variable was available everywhere, but it seems not. What version of Vim are you using, and on which OS?

Btw, I won't have time to follow up before Friday. Should be able to help you then.

[Rmano]

Ok, no problem. vim 2:7.4.052-1ubuntu3 on a Ubuntu 14.04 Trusty, fully up-to-date.

[Rmano]

Yep. I do not have v:progpath variable; seem they have introduced it in 7.4.234, see http://ftp.nluug.nl/editors/vim/patches/7.4/7.4.234

This patch will solve it:

diff --git a/autoload/latex.vim b/autoload/latex.vim
index d7b15cb..f204c0c 100644
--- a/autoload/latex.vim
+++ b/autoload/latex.vim
@@ -113,6 +113,7 @@ function! s:init_environment() " {{{1
   "
   call latex#util#set_default('g:latex#data', [])
   call latex#util#set_default('b:latex', {})
+  call latex#util#set_vim_executable()

   "
   " Set some file type specific vim options
diff --git a/autoload/latex/latexmk.vim b/autoload/latex/latexmk.vim
index 580ddb7..e999688 100644
--- a/autoload/latex/latexmk.vim
+++ b/autoload/latex/latexmk.vim
@@ -339,7 +339,7 @@ function! s:latexmk_set_cmd(data) " {{{1
   if g:latex_latexmk_continuous
     let cmd .= ' -pvc'
     if g:latex_latexmk_callback && has('clientserver')
-      let callback  = v:progpath
+      let callback  = g:latex_vim_executable
       let callback .= ' --servername ' . v:servername
       let callback .= ' --remote-expr \"latex\#latexmk\#errors(0)\"'
       if has('win32')
diff --git a/autoload/latex/util.vim b/autoload/latex/util.vim
index 28665d3..39c2af8 100644
--- a/autoload/latex/util.vim
+++ b/autoload/latex/util.vim
@@ -359,6 +359,24 @@ function! latex#util#set_default_os_specific(variable, default) " {{{1
   endif
 endfunction
+function! latex#util#set_vim_executable() " {{{1
+  
+  if exists('v:progpath')
+    let g:latex_vim_executable = v:progpath
+    return 
+  endif
+
+  if exists('g:latex_vim_executable') | return | endif
+
+  if (has('unix') && system('uname') =~ 'Darwin')
+        \ || has('macunix')
+        \ || has('gui_mac')
+    let g:latex_vim_executable = 'mvim'
+  else
+    let g:latex_vim_executable = 'vim'
+  endif
+endfunction
+
 function! latex#util#tex2tree(str) " {{{1
   let tree = []
   let i1 = 0

[Konfekt]

Oh. Sorry for the inconvenience. Try instead v:progname that has been around since Vim 6.

As long as Vim is in your path, that's sufficient after all. There's also echo exepath(v:progname) to try to get the full path.

[Rmano]

Yes, I have v:progname --- so I should simply change v:progpath for v:progname? I think that the supposition that the program is in the path will stand practically always.

[Konfekt]

Yes, the way it is used at 356c577 shows that this is sufficient.

Best is to wait until Karl accepts the pull request so that your local copy does not go out of sync with that one here if you happen to use a plugin manager such as Vundle.

[Konfekt]

The advantage of v:progpath is that you don't even have to have Vim in your path to setup inverse and forward search for example.

[Rmano]

Patch tested, it works. Thanks.

[lervag]

Sorry for not replying sooner. It seems @Konfekt has solved the issue. I might improve upon it slightly by applying a patch to use v:progpath if it is available, but for now it seems that everything works as expected. Thanks @Konfekt for contributing, and thanks @Rmano for reporting the issue!