\ll starts two viewers

[st-bender]

Description

Using \ll to compile and view the pdf leads to two open windows with the pdf.

Steps to reproduce

1. Create or open a latex file (the minimal example at the bottom, for example)
2. Press \ll for compilation

Expected behavior

One window opens with the compiled document.

Actual behavior

Two windows open with the compiled document.

Do you use a latexmkrc file?

yes

VimtexInfo

System info:
  OS: Ubuntu 18.04.6 LTS
  Vim version: VIM 8.0 (1-1453)
  Has clientserver: true
  Servername: undefined (vim started without --servername)

VimTeX project: project
  base: project.tex
  root: /home/user/Documents/project
  tex: /home/user/Documents/project/project.tex
  main parser: current file verified
  document class: scrartcl
  packages: SIunits adjcalc adjustbox amsbsy amsfonts amsgen amsmath amsopn amssymb amstext auxhook babel biblat
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
    job: 
      jobid: process 23962 run
      output: /tmp/vli0TXx/1
      cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -
      pid: 23962
  viewer: MuPDF
    xwin id: 167772235

[lervag]

You did not provide the information asked for in the issue template.

Notice that I specifically ask for minimal test files. I can't do magic, so to help you, I need to know the details.

You answered "yes" to the latexmkrc question - is there a reason you do not think it is relevant to the problem?

[st-bender]

Use the minimal "hello world" tex file in the issue template.
Edit: or any .tex file actually, it is consistent here.

The latexmkrc sets the compiler to pdf output and xelatex, and the viewer is mupdf, sorry I forgot to mention that, here it is, in case it is relevant.

$pdf_mode = 1;
$pdflatex = 'xelatex -synctex=1 -interaction=nonstopmode --shell-escape %O %S';
$xelatex = 'xelatex -synctex=1 -interaction=nonstopmode --shell-escape %O %S';

[lervag]

I've pushed a minor fix, although it seems unrelated to the issue. But please update.

What's the output of :VimtexInfo after you open a minimal LaTeX file and do \ll? I'm specifically interested in the section viewer: MuPDF.

[st-bender]

Bisecting found that 3babc07 is the first bad commit, if that helps.

[st-bender]

Thanks for the update.
Still happening, here is the info from minimal.tex after \ll, some of the lines seem to be truncated by the terminal. I can try to get the full length if you think they are important.

VimTeX project: minimal
  base: minimal.tex
  root: /home/user/Documents/minimal_latex
  tex: /home/user/Documents/minimal_latex/minimal.tex
  main parser: current file verified
  document class: minimal
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
    job: 
      jobid: process 28674 run
      output: /tmp/v301gS7/0
      cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -
      pid: 28674
  viewer: MuPDF
    xwin id: 167772235
    cmd_synctex_view: synctex view -i 2:2:'/home/user/Documents/minimal_latex/minimal.tex' -o '/home/user
    cmd_forward_search: xdotool type --window 167772235 "1g"
    cmd_start: mupdf '/home/user/Documents/minimal_latex/minimal.pdf'&
  qf method: LaTeX logfile

[lervag]

I've pushed a commit that I believe fixes the issue. But I'll also consider the callback changes I made earlier, as they may lead to other undesired problems.

Thanks for reporting!

[lervag]

I believe my last commit would also be a sufficient fix for this issue. The problem was caused by "duplicate" callbacks, in the sense that latexmk will first report "Running 'echo vimtex_compiler_callback_...'", then in some cases/setups it will also display the echo output "vimtex_compiler_callback_..." just afterwards. Both would be matched by the callback handler, which would therefore cause two callbacks for each event.

In any case, I believe the issue is resolved and the code is slightly improved as a result. Thanks again!

[st-bender]

Thanks very much, looks good to me.
Not sure if it is limited to mupdf, but your other explanation makes sense.

[st-bender]

I've pushed a commit that I believe fixes the issue. But I'll also consider the callback changes I made earlier, as they may lead to other undesired problems.

Thanks for reporting!

Hi @lervag
I noticed that with 303da16 the pdf shown with mupdf is not updated anymore when saving the file and I have to refresh manually. A short test shows that reverting that commit fixes that.

Sorry for commenting on a closed issue, should I open a new issue?

[lervag]

That's strange. I can't reproduce this on my end. Could you provide some more details on how to reproduce? I've tried with both Vim and neovim, both work perfectly fine for me. I used the following minimal files:

" test.vim
set nocompatible
set rtp^=/path/to/vimtex
set rtp+=/path/to/vimtex/after
filetype plugin indent on
syntax enable

nnoremap q :qall!<cr>

let g:vimtex_view_method = 'mupdf'

silent edit main.tex

% test.tex
\documentclass{minimal}
\begin{document}
Hello world!
\end{document}

Then I do nvim --clean -u test.vim or vim -u test.vim.

[st-bender]

Oddly enough, I cannot reproduce it anymore.
Sorry for the false alarm.