Unsetting `g:vimtex_view_forward_search_on_start` results in zathura being opened twice

[donbex]

Issue
Setting g:vimtex_view_forward_search_on_start = 0 and starting latexmk via <plug>(vimtex-compile-toggle) results in zathura being opened twice. I haven't tested this with another viewer.

minimal.vim

set nocompatible
let &runtimepath  = '~/.vim/bundle/vimtex,' . &runtimepath
let &runtimepath .= ',~/.vim/bundle/vimtex/after'
filetype plugin indent on
syntax enable
let g:vimtex_view_forward_search_on_start = 0
let g:vimtex_view_method = 'zathura'

minimal.tex

\documentclass{minimal}
\begin{document}
Hello world!
\end{document}

Commands/Input
After starting nvim, run latexmk via \ll.

Observed Behaviour
A zathura window is opened, the terminal running nvim flashes while latexmk is running, then a second zathura window is opened.

Expected Behaviour
Only one zathura window is opened.

Note
When g:vimtex_view_forward_search_on_start is set to 1, \ll first opens a zathura window, then shows the synctex location after the first compilation is finished. This leads me to believe that zathura is called twice in both cases.

Update
g:vimtex_view_forward_search_on_start = 0 also appears to break normal forward search via \lv.

Output from VimtexInfo

System info
  OS: Arch Linux
  Vim version: NVIM v0.4.3
  Has clientserver: true
  Servername: /tmp/nvimUjrwO1/0

vimtex project: minimal
  base: minimal.tex
  root: /tmp/vimtex
  tex: /tmp/vimtex/minimal.tex
  out: /tmp/vimtex/minimal.pdf
  log: /tmp/vimtex/minimal.log
  aux: /tmp/vimtex/minimal.aux
  fls: /tmp/vimtex/minimal.fls
  main parser: current file verified
  compiler: latexmk
    configuration: 
      continuous: 1
      callback: 1
      latexmk options:
        -verbose
        -file-line-error
        -synctex=1
        -interaction=nonstopmode
      latexmk engine: -pdf
    job: 3
    pid: 91938
    cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -e '$new_viewer_always = "0"' -e '$pdf_previewer = "zathura  -x \"nvr --servername /tmp/nvimUjrwO1/0 --remote +\%{line} \%{input}\" \%S"' -e '$success_cmd = "echo vimtex_compiler_callback_success"' -e '$failure_cmd = "echo vimtex_compiler_callback_failure"' 'minimal.tex'
  viewer: Zathura
    xwin id: 10485763
    process: 
      pid: -
      cmd: zathura -x "nvr --servername /tmp/nvimUjrwO1/0 --remote-expr \"vimtex#view#reverse_goto(%{line}, '%{input}')\""  '/tmp/vimtex/minimal.pdf' >/dev/null 2>&1 &
  qf: LaTeX logfile
    config: 
      packages: 
        default: 1
      default: 1
  document class: minimal

[lervag]

The option g:vimtex_view_forward_search_on_start only affects the behaviour when you open the viewer with \lv. That is, it does not do anything when the viewer is opened automatically after \ll. The following should explain:

• \ll: Starts the compiler. With latexmk, the viewer is typically opened automatially (unless g:vimew_view_automatic is disabled). This is done by latexmk (a perl script running in its own subshell/-process). Vimtex does set some options to specify the viewer and viewer options, but these options may be overridden by your own .latexmkrc file. The option g:vimtex_view_forward_search_on_start does not affect anything here.

  Note: After compilation is finished, there will be a compiler callback which calls the function vimtex#compiler#callback, which in turn calls vimtex#view#zathura#compiler_callback. This function is used to 1) capture the xwindow ID for Zathura instances e.g. as started by latexmk, and 2) to start Zathura if a viewer window is not found.

• \lv: Starts the viewer and/or performs a forward search. The "and" is effective if g:vimtex_view_forward_search_on_start is enabled, and this is the only point in which this option is relevant.

For me, things work as described above, and I was not able to reproduce any unexpected behaviour. I'm curious if the problem may be that the docs lead to wrong expectations instead?

[donbex]

For me, things work as described above, and I was not able to reproduce any unexpected behaviour. I'm curious if the problem may be that the docs lead to wrong expectations instead?

Indeed, that appears to be the case.

However, I would still like to be able to prevent \ll from resulting in a forward search. I do not have a custom .latexmkrc, nor I have changed the compilation options through g:vimtex_compiler_latexmk. Is there a way to achieve this, either through vimtex or through latexmk? If so, it might be useful to include a note about it in the documentation, or at least in the wiki.

[lervag]

However, I would still like to be able to prevent \ll from resulting in a forward search. I do not have a custom .latexmkrc, nor I have changed the compilation options through g:vimtex_compiler_latexmk. Is there a way to achieve this, either through vimtex or through latexmk? If so, it might be useful to include a note about it in the documentation, or at least in the wiki.

Strange. For me, \ll does not result in a forward search. Not with my personal settings, nor with the minimal settings from your original post.

I'm curious, do you have xdotool installed? Are you on Wayland or X11?

[donbex]

I'm curious, do you have xdotool installed? Are you on Wayland or X11?

Ah, that might be it... I do have xdotool installed, but I am also on Wayland (Sway, to be precise). Both the terminal running nvim and zathura are Wayland-native windows.

[lervag]

Yes, that explains it. And I'm sorry to say I don't know a way to fix this directly. I think you either need to 1) use X11, or 2) rely on the general viewer mechanism.

Note: With swaymsg it could be possible to implement something similar to what we do now with xdotool. However, I don't use Wayland myself, so I won't implement it. I commands like these would be relevant:

id=$(swaymsg -t get_tree \
  | jq -r '..| try select(.app_id == "org.pwmt.zathura") | select(.visible == true) | select(.pid == 11693) | .id')
swaymsg "[con_id=$id] focus"

So, with that, I'm sorry to say I don't see a way to actually fix the issue, thus I take the liberty of closing it.

[donbex]

I understand. However, what exactly is xdotool being used for, and is there a way to override those commands with, say, a Wayland equivalent?

[lervag]

xdotool is used to capture the X window ID, which is used to avoid opening multiple instances (which is the original issue here!).

And yes, I think you could use something like swaymsg to replace xdotool, but there is no mechanism for this directly. I would be happy to accept a PR. One possibility would be to make a new viewer:

1. Make a new file autoload/vimtex/view/viewer.vim based on the code from autoload/vimtex/view/common.vim and autoload/vimtex/view/zathura.vim (you can put this anywhere in your runtimepath, or simply in the vimtex repo; up to you).

2. Merge the contents of common.vim and zathura.vim to make it more clear what is needed for a new zathura version that works with Wayland.

3. Change all uses of xdotool to e.g. swaymsg so that things work with Wayland and Sway.

If you do this, then I would be very happy to help merge it!

[tyr898]

A similar thing is happening with WSL on Windows. I'm not entirely sure of the mechanics, but these are the only settings I have:

let g:tex_flavor = 'latex'
let g:vimtex_view_method = 'zathura'

and doing \ll results in two zathura windows opening. Changing the value of g:vimtex_view_forward_search_on_start does nothing to fix this. \lv only opens a single window.

I have vcxsrv installed on Window to get linux applications working, and also have xdotool installed. Should I create a new issue detailing exactly what I'm facing? Wondering if it would be a quick fix.

The two window problem is also happening for mupdf.

[lervag]

A similar thing is happening with WSL on Windows. I'm not entirely sure of the mechanics, but these are the only settings I have:
...
Should I create a new issue detailing exactly what I'm facing?

Yes, please. It will be very good if you can provide a clear and concise description of your system and configuration. You could also check if xdotool works from your terminal and comment on that.