`g:vimtex_view_forward_search_on_start` not working when `g:vimtex_view_method = "zathura_simple"`
Description
I'm not sure that this is strictly a "bug", as the documentation does say that this option only applies when g:vimtex_view_method is set to zathura or mupdf, but I was assuming that it would also work for zathura_simple.
To be clear: when using zathura_simple rather than zathura, the forward search and the resulting highlighting occurs when the viewer window is first opened.
This is a relatively standard Linux/Neovim/Vimtex/Zathura setup. I'm using zathura_simple rather than zathura as I'm using Wayland, so xdotool isn't available.
Steps to reproduce
I can include config files and minimal example files if required, but this is from a very basic, standard Linux/Neovim/Vimtex/Zathura setup.
When:
g:vimtex_view_forward_search_on_start = 0g:vimtex_view_method = "zathura"
Then the initial search and highlighting doesn't happen on first compile.
When:
g:vimtex_view_forward_search_on_start = 0g:vimtex_view_method = "zathura_simple"
The initial search and highlighting happens on first compile.
Expected behavior
With:
g:vimtex_view_forward_search_on_start = 0g:vimtex_view_method = "zathura_simple"
I would expect the initial forward search and highlighting not to happen after the initial call to :VimtexCompile.
Actual behavior
With:
g:vimtex_view_forward_search_on_start = 0g:vimtex_view_method = "zathura_simple"
The initial forward search and highlighting happens after the initial call to :VimtexCompile.
Do you use a latexmkrc file?
Yes, but it's not relevant.
VimtexInfo
System info:
OS: Arch Linux
LaTeX version: pdfTeX 3.141592653-2.6-1.40.27 (TeX Live 2026/dev/Arch Linux)
Vim version: NVIM v0.11.4
Has clientserver: true
Servername: /run/user/1000/nvim.24148.0
$PATH:
- /$HOME/.local/bin
- $HOME/.local/share/nvim/mason/bin
- $HOME/bin
- /opt/cuda/bin
- /opt/cuda/nsight_compute
- /opt/cuda/nsight_systems/bin
- /usr/bin
- /usr/bin/core_perl
- /usr/bin/site_perl
- /usr/bin/vendor_perl
- /usr/lib/jvm/default/bin
- /usr/lib/rustup/bin
- /usr/local/bin
- /usr/local/sbin
VimTeX project: <project>
base: <project.tex>
root: $HOME/<PATH>
tex: $HOME/<PATH>/<TEXFILE>.tex
main parser: current file verified
document class: beamer
document class options: aspectratio=169
packages: amsbsy amsfonts amsgen amsmath amsopn amssymb amstext amsthm atbegshi-ltx atveryend-ltx beamerbaseauxtemplates beamerbaseboxes beamerbasecolor beamerbasecompatibility beamerbasedecode beamerbasefont beamerbaseframe beamerbaseframecomponents beamerbaseframesize beamerbaselocalstructure beamerbasemisc beamerbasemodes beamerbasenavigation beamerbasenotes beamerbaseoptions beamerbaseoverlay beamerbaserequires beamerbasesection beamerbasetemplates beamerbasethemes beamerbasetheorems beamerbasetitle beamerbasetoc beamerbasetranslator beamerbasetwoscreens beamerbaseverbatim beamercolorthemedefault beamercolorthemeorchid beamercolorthemestructure beamercolorthemewhale beamerfontthemedefault beamerinnerthemedefault beamerinnerthemerectangles beamerouterthemedefault beamerouterthemesidebar beamerthemeBanburyBelow beamerthemeRochester beamerthemedefault bigintcalc bitset caption caption3 enumerate environ epstopdf-base etoolbox expl3 fontenc fontspec fontspec-luatex geometry gettitlestring graphics graphicx hycolor hyperref ifluatex iftex ifvtex include/beamerthemeBanburyBelow infwarerr intcalc keyval kvdefinekeys kvoptions kvsetkeys ltxcmds nameref pdfescape pdftexcmds pgf pgfcomp-version-0-65 pgfcomp-version-1-18 pgfcore pgfkeys pgfmath pgfrcs pgfsys refcount rerunfilecheck sansmathaccent scrlfile scrlfile-hook scrlogo stringenc translator trig trimspaces uniquecounter url xcolor xltxtra xparse xxcolor
source files:
<project.tex>
include/boilerplate.tex
include/slidetypes.tex
compiler: latexmk
engine: -pdf
options:
-verbose
-file-line-error
-synctex=1
-interaction=nonstopmode
callback: 1
continuous: 1
executable: latexmk
viewer: Zathura
qf method: LaTeX logfile
I'm not sure that this is strictly a "bug", as the documentation does say that this option only applies when
g:vimtex_view_methodis set tozathuraormupdf, but I was assuming that it would also work forzathura_simple.
No, it's not a bug, it's by design. The zathura_simple layer does not really know if the Zathura viewer is open or not, thus that option does not really make sense. That is, every invocation of \lv must assume perform the forward search, unless you disable the synctex support for g:vimtex_view_zathura_use_synctex. However, this also disables the inverse search feature.
I could allow g:vimtex_view_forward_search_on_start = 0 to disable forward search similar to how it does with the zathura viewer, but then you would not be able to actually do a forward search, and I don't think that you want that?
Thanks for the quick reply! I imagined that there was a good reason why this wouldn't work, but thought it was worth reporting just in case.
No, definitely best to leave forward searching working!
I assume that this is to do with xdotool? What specific features of that are used for this? (I'm just wondering if one of the replacements for Wayland, like ydotool, dotool, can achieve the same behaviour?)
Thanks for the quick reply! I imagined that there was a good reason why this wouldn't work, but thought it was worth reporting just in case.
No, definitely best to leave forward searching working!
:+1:
I assume that this is to do with
xdotool? What specific features of that are used for this? (I'm just wondering if one of the replacements for Wayland, likeydotool,dotool, can achieve the same behaviour?)
Well, partly. On Xorg we can use xdotool both to "ask" for X window info and to control the windows. In VimTeX, we use it both to detect the Zathura instance and thus keep track of the state from within VimTeX, and also for some limited control.
I do think we can achieve something similar on Wayland. I still use Xorg myself, though, so I've never spent time on that.