Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No compiler output using arara, gvim on win32 #1068

Closed
lucasreddinger opened this issue Mar 1, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@lucasreddinger
Copy link

commented Mar 1, 2018

Hi,

I'm trying to get vimtex to compile using arara on Windows 7 (sorry!) running gvim.

arara works nicely on the command line (cmd, powershell, and git bash). However, when I try to compile with vimtex, a window appears and immediately disappears on the taskbar, too quickly to discern anything. No compiler output is stored in the temp file referenced by :VimtexCompileOutput, and no arara.log is saved. I don't know how to debug this, or I would! I spent some time reading the arara-specific compiler code, but I think someone may be able to answer my question quickly.

Is there a way that I can echo the exact command that vimtex is trying to execute for compilation? Maybe then I could see what's wrong. Thanks much!!


  1. Minimal ~/_vimrc file:
set nocompatible
let &rtp  = '~/.vim/plugged/vimtex,' . &rtp
let &rtp .= ',~/.vim/plugged/vimtex/after'

let g:vimtex_compiler_method='arara'
let g:vimtex_view_method='mupdf'
let g:vimtex_view_forward_search_on_start=0
  1. Minimal main.tex file:
% arara: pdflatex
\documentclass{minimal}
\begin{document}
Hello World!
\end{document}
  1. Steps to reproduce:

    • Run gvim E:\demo\main.tex.

    • Run :VimtexCompile. A window opens and closes almost instantaneously. Meanwhile, in gVim, a new status is reported:

      vimtex: Compiler started in background

    • Run :VimtexCompileOutput. An empty file is opened, with a path like ~/AppData/Local/Temp/ABCD123.tmp.


I'm assuming this is unrelated, but xdotool doesn't support windows. Accordingly, on startup, I get a notice:

> vimtex: MuPDF requires xdotool!

I was hoping that vimtex would let me use MuPDF without xdotool by setting

let g:vimtex_view_forward_search_on_start=0

However, it seems to have disabled :VimtexView.

lervag added a commit that referenced this issue Mar 1, 2018

@lervag

This comment has been minimized.

Copy link
Owner

commented Mar 1, 2018

First, I took the liberty of freshing up your issue post with some more formatting and a more minimal vimrc file.

Let's start with MuPDF. I've pushed an update that I think should make it work. Please test.

About the main issue. Which version of Vim are you on? Could you give me the output of \li after opening the main.tex file?

@lucasreddinger

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

First, I really appreciate your response and help!

re: MuPDF--Yes, the error message about xdotool is no longer displayed. Thanks!


Regarding the main issue, my version is:

VIM - Vi Improved 7.4 (2013 Aug 10), MS-Windows 32-bit GUI version with OLE support.

I'd check for a newer version of Vim, but vim.org is not responding--I think all SourceForge websites are offline.

Here is an unrelated error message I get upon starting Vim, since pulling the updates.

Here is the output from \li, following \ll.

(Sorry about using image captures, but I couldn't manage to copy either texts, and I didn't want to make an error.)

BTW, I tried the ~/.vimrc you posted, but it didn't work to load vimtex, so I'm using this ~/.vimrc:

set nocompatible
call plug#begin('~/.vim/plugged')
Plug 'lervag/vimtex'
call plug#end()

let g:vimtex_compiler_method='arara'
let g:vimtex_view_method='mupdf'
let g:vimtex_view_forward_search_on_start=0
@lervag

This comment has been minimized.

Copy link
Owner

commented Mar 4, 2018

Ok. I believe this issue might be resolved directly if you use Vim 8, which should be available for Windows here. Can you update and report back?

@lucasreddinger

This comment has been minimized.

Copy link
Author

commented Mar 5, 2018

Updated to Vim 8. Compilation with arara now works! Thanks!

capture_2018-03-05_0006

\lv is not opening the pdf in mupdf, as expected. I can run mupdf from the command line successfully, so $PATH includes the mupdf.exe location.

If I'm understanding the limitation of not having xdotool, even if vimtex can open the pdf in mupdf, it can't send mupdf an r keystroke to reload the file, correct? (I realize it can't search through the file, as explained elsewhere, without xdotool.)

Beyond that, this addresses the scope of the original issue. And I think this gives Windows users a pretty decent workflow. One can compile and re-compile from Vim. To view output, however, one must Alt-Tab to mupdf and press r to reload the file (or open it, if mupdf isn't already open).

If I'm missing anything that could make the Windows vimtex experience better, I'd love to hear.

Thanks again!


Side notes: Still getting a couple quirky error messages with Vim 8. I can't tell what the effect of these are; maybe they don't matter at all.

lervag pushed a commit that referenced this issue Mar 6, 2018

Karl Yngve Lervåg
@lervag

This comment has been minimized.

Copy link
Owner

commented Mar 6, 2018

  • I'm very happy to hear that Arara works! :)
  • I don't quite understand why mupdf suddenly stopped working. Perhaps the $PATH is not properly set (even though it seems like it from the command line)? Check :echo $PATH inside Vim. If you still can't get it to work, please open a new issue for this.
  • And yes, you need xdotool to make MuPDF update after compilation and to synchronize the views (only on page level). I am not interested in finding other alternatives to xdotool on Windows, but if you should find any you are welcome to submit a PR.
  • As for suggestions: How about using SumatraPDF? I have the impression this is more standard on Windows and that it works quite well. See :h vimtex_viewer_sumatrapdf.
  • I've seen the startup-error a couple of times now from different people, and I would be very happy to solve this once and for all. Again, could you open a new issue for it? Please provide a minimal description of how to replicate.
  • The last error was due to a minor bug in the mupdf viewer, and I think it is fixed now.
@lervag

This comment has been minimized.

Copy link
Owner

commented Mar 6, 2018

I'm closing this, as it seems the remaining issues should be opened as new issues.

@lervag lervag closed this Mar 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.