Neovim gets Stuck when Continuous Compiling is started

[moreiramn]

Issue
When I turn the Continuous Compiling with \ll, my Neovim instance turns blank with a blinking cursor, and after a few seconds it comes back to normal at the same time the forward search indicator on Zathura is trigered.

I noticed that if I put

let g:vimtex_compiler_latexmk = {'callback': 0}

on my init.vim, this behavior does not show up

• neovim: nvim -u minimal.vim minimal.tex

minimal.vim

set directory=~/.vim/.tmp//
set backupdir=~/.vim/.backup//
set undodir=~/.vim/.undo//
set termguicolors
call plug#begin()
Plug 'lervag/vimtex'
call plug#end()
colorscheme onedark
let g:onedark_termcolors=256
hi Normal ctermbg=NONE guibg=NONE

let g:vimtex_view_method = 'zathura'
let g:vimtex_compiler_progname = 'nvr'
let g:tex_flavor = "latex"

minimal.tex

\documentclass{article}

\title{}
\author{}

\begin{document}

\maketitle

helloworld

t
\end{document}

Commands/Input
\ll

Observed Behaviour
I am attaching a video to showcase it, but as I stated above, my Nvim gets stuck in a blank background with a blinking cursor.

Expected Behaviour
As I start continuous compiling Zathura should start with no blocks

Output from VimtexInfo

System info
  OS: Fedora release 33 (Thirty Three)
  Vim version: NVIM v0.4.4
  Has clientserver: true
  Servername: /tmp/nvimvHF2TD/0

VimTeX project: teste
  base: teste.tex
  root: /home/fcomoreira
  tex: /home/fcomoreira/teste.tex
  out: /home/fcomoreira/teste.pdf
  log: /home/fcomoreira/teste.log
  aux: /home/fcomoreira/teste.aux
  fls: /home/fcomoreira/teste.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: 4
    pid: 27695
    cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -view=none -e '$success_cmd = "echo vimtex_compiler_callback_success"' -e '$fai
  viewer: Zathura
    xwin id: 54525955
    process:
      pid: -
      cmd: zathura -x "nvr --servername /tmp/nvimvHF2TD/0 --remote-expr \"vimtex#view#reverse_goto(%{line}, '%{input}')\"" --synctex-forward 11:1:'/home/fcomoreira/teste.tex'  '/home/fcomo
    cmd_forward_search: zathura --synctex-forward 13:1:'teste.tex' 'teste.pdf'
  qf: LaTeX logfile
    root: /home/fcomoreira
    addqflist: 59
    errorformat_saved:
    fix_paths: 60
    main: /home/fcomoreira/teste.tex
    set_errorformat: 58
  document class: article

githubIssue.mp4

[lervag]

When I turn the Continuous Compiling with \ll, my Neovim instance turns blank with a blinking cursor, and after a few seconds it comes back to normal at the same time the forward search indicator on Zathura is trigered.

I believe the problem is related to these lines:

vimtex/autoload/vimtex/view/zathura.vim

Lines 52 to 56 in d99f8ff

	for l:dummy in range(30)
	let l:xwin_exists = self.xwin_exists()
	if l:xwin_exists | break | endif
	sleep 50m
	endfor

Can you verify that by commenting this out or simply adding return just above? to prevent the for loop to execute?

Note: Your minimal vimrc file seems not fully minimal to me. I would expect you can simplify it further:

minimal.vim

call plug#begin()
Plug 'lervag/vimtex'
call plug#end()

let g:vimtex_view_method = 'zathura'

minimal.tex

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

Given the above, can you still reproduce with nvim -u minimal.vim minimal.tex?

You should also note that these settings are not necessary (nvr is selected by default, if available and you use nvim; g:tex_flavor is only relevant if you set it to something else than "latex").

let g:vimtex_compiler_progname = 'nvr'
let g:tex_flavor = "latex"

[moreiramn]

return
 for l:dummy in range(30) 
   let l:xwin_exists = self.xwin_exists() 
   if l:xwin_exists | break | endif 
   sleep 50m 
 endfor 

Adding a return just above the lines you mentioned did the trick. I tried just commenting, but received some errors because the code just after it used some variables declared inside the loop.

I don't know exactly what this part should be doing, but if it won't break any other feature, I would consider it solved!

Thank you so much for your fast response and solution, your plugin is awesome!

[lervag]

I don't know exactly what this part should be doing, but if it won't break any other feature, I would consider it solved!

Ah, no, it is not solved (unless you want to run your own fork). But I know where this happens, which is a start. :)

Thank you so much for your fast response and solution, your plugin is awesome!

Happy to hear it!

---

So, to continue the bug hunt: can you reproduce the issue with my minimal example?

If so: which version of xdotool are you using? Are you using Wayland or X.org? And finally, open a pdf in Zathura and open a terminal, then do: xdotool search --class Zathura - what's the output?

[szbernat]

Hey. I have the same problem, it has been bothering me for some time now. I am using vim. Adding the return statement where you suggested fixes the problem for me as well. The problem persists with the minimal configuration and tex file you provided.

Also: I am using X.org.

xdotool --version
xdotool version 3.20160805.1

After opening a pdf in Zathura the output of xdotool search --class Zathura is two numbers:

56623105
56623107

Thanks for the help and for the awesome plugin!

[lervag]

Hey. I have the same problem, it has been bothering me for some time now. I am using vim. Adding the return statement where you suggested fixes the problem for me as well. The problem persists with the minimal configuration and tex file you provided.

Ok. Thanks for providing the additional information! Can you test again with the same test.tex but this test.vim file:

set nocompatible
let &rtp = '~/.vim/bundle/vimtex,' . &rtp
filetype plugin on

let g:vimtex_view_method = 'zathura'

In a terminal, do:

1. vim --servername vim -u test.vim test.tex
2. \ll to compile

If I've understood correctly, this should reproduce the problem for you. Can you confirm?

If so, then I'd be happy to do some debugging with your help to figure out what is wrong.

Thanks for the help and for the awesome plugin!

I'm glad you like it!

[szbernat]

So I am using vim-plug as my plugin manager, therefore your above test.vim didn't work for me. However with this one I can reproduce the issue by typing vim --servername vim -u test.vim test.tex followed by \ll:

set nocompatible
call plug#begin()
Plug 'lervag/vimtex'
call plug#end()
filetype plugin on

let g:vimtex_view_method = 'zathura'

This should be equivalent to what you suggested, right?

If so, then I'd be happy to do some debugging with your help to figure out what is wrong.

That would be great!

[lervag]

So I am using vim-plug as my plugin manager, therefore your above test.vim didn't work for me.

That's not right. The reason it did not work was because the runtime path was not right. I forgot to mention that: you need to update let &rpt = ... to the actual path to VimTeX. I believe it might be ~/.vim/plugged by default (just check that in a terminal).

Note, this is not crucial, but since we are looking at a minimal example, there is no reason to also include vim-plug.

---

Still, I understand that with the minimal example, you can still reproduce the issue (it might have been implied, but you did not state it explicitly)?

[szbernat]

I forgot to mention that: you need to update let &rpt = ... to the actual path to VimTeX.

Ok, this was it. Now my test.vim looks like this:

set nocompatible
let &rtp = '~/.vim/plugged/vimtex,' . &rtp
filetype plugin on

let g:vimtex_view_method = 'zathura'

And vim still hangs for a couple of seconds then the forward search is still triggered after starting the compilation with \ll. So the problem is still present with this minimal example.

[lervag]

Great, thanks.

Now, can you edit ~/.vim/plugged/vimtex/autoload/vimtex/view/common.vim:

• Find the function s:xwin_template.xwin_exists().
• Notice that there are some conditionals.
• Add lines like unsilent echom "testing" self.xwin_id, e.g. above line 143 and below line 148
• The goal is to figure out where this function ends up - for some reason, it will return the value 0 (which is false) and find xwin_id = 0. If with some simple echo debugging you can help me locate which line is the last one in this function that is executed, that will be helpful.

A simple editing loop is like this:

1. Perform an edit as desribed above.
2. In a different terminal, run vim --servername vim -u test.vim test.tex, do \ll, and observe the results:
3. Repeat from 1 until you learn something useful.

[szbernat]

Here is what I found:

After compilation is started with \ll, the function s:xwin_template.xwin_exists is called several times (maybe 20-25) in quick succession. Each time the value of self.xwin_id is 0 when entering the function, therefore this conditional doesn't execute:

vimtex/autoload/vimtex/view/common.vim

Lines 143 to 148 in 1fe16bf

	if self.xwin_id > 0
	let cmd = 'xdotool search --class ' . self.class
	if index(split(system(cmd), '\n'), self.xwin_id) < 0
	let self.xwin_id = 0
	endif
	endif

Instead, this part is entered every time:

vimtex/autoload/vimtex/view/common.vim

Lines 153 to 160 in 1fe16bf

	if self.xwin_id == 0
	let l:pid = has_key(self, 'get_pid') ? self.get_pid() : 0
	if l:pid > 0
	let cmd = 'xdotool search'
	\ . ' --all --pid ' . l:pid
	\ . ' --name ' . fnamemodify(self.out(), ':t')
	let self.xwin_id = get(split(system(cmd), '\n'), 0)
	else

On line 154, l:pid will get a different positive value in every execution and so the conditional starting on line 155 is executed. Here however system(cmd) always returns empty. I also executed the contents of cmd in a separate terminal where it also returned nothing. This is the content of cmd (with a different PID in each of the 20-25 rapid executions):
xdotool search --all --pid 572060 --name test.pdf
I tried to look for running processes matching the value of l:pid but found none (I am not sure which process's ID self.get_id() should return here?). Finally, since system(cmd) always returns empty, the value of self.xwin_id is set to 0 zero on line 159 and the function returns false on line 176.

I hope this helps.

[lervag]

After compilation is started with \ll, the function s:xwin_template.xwin_exists is called several times (maybe 20-25) in quick succession.

Yes, actually, 30 times:

vimtex/autoload/vimtex/view/zathura.vim

Lines 52 to 56 in 1fe16bf

	for l:dummy in range(30)
	let l:xwin_exists = self.xwin_exists()
	if l:xwin_exists | break | endif
	sleep 50m
	endfor

Instead, this part is entered every time: ...

Thanks, that's very useful info!

So, it seems the problem is related to a couple of calls, something like this:

• pgrep -nf "zathura.*test.pdf"
  This should return the PID of an already running Zathura session. You should be able to check if this works by first opening zathura test.pdf in a terminal, then running the pgrep command. Inspect the return pid with e.g. ps aux|grep PID.

• pgrep -nf "zathura.+--servername VIM"
  Same as above; if the above does not match, then this one might.

• If the pgrep does return a nonzero PID, then we do this:
  xdotool search --all --pid PID --name test.pdf
  So, given the PID from the above commands, you could test this xdotool command and give me some feedback on what output you observe.

I tried to look for running processes matching the value of l:pid but found none (I am not sure which process's ID self.get_id() should return here?).

We are looking for an already existing Zathura process, e.g. one started by latexmk. The -pvc option for latexmk actually tells it to open the viewer, and VimTeX hooks into this and provides the relevant view options for Zathura (see the s:zathura.latexmk_append_argument() function).

---

I would be glad if you could test some of the above pgrep and xdotool commands and give me some feedback on the outputs in a regular terminal.

A variant: Do the same as above, but instead of opening Zathura manually, open it from VimTeX like this: i) open test.tex in VimTeX, ii) do \ll to ensure it is compiled; close any opened viewers, iii) open a viewer with \lv. Now test the pgrep and xdotool commands.

[szbernat]

Both of your pgrep commands are able to find the correct pid for me, when Zathura is opened manually and also when it is opened from vim with \lv. With this pid xdotool returns a single number, which I assume is the correct xwin_id for the Zathura window.

I echoed the pid variable from the s:zathura.get_pid function in zathura.vim as well. These lines don't find anything since they try to look for the output file by its full path, but the actual process only has the relative path (test.pdf) in its name:

vimtex/autoload/vimtex/view/zathura.vim

Lines 133 to 135 in 1fe16bf

	let cmd = 'pgrep -nf "zathura.*'
	\ . escape(get(self, 'outfile', self.out()), '~\%.') . '"'
	let pid = str2nr(system(cmd)[:-2])

And the second attempt finds the 30 different but incorrect pids:

vimtex/autoload/vimtex/view/zathura.vim

Lines 138 to 141 in 1fe16bf

	if empty(pid)
	let cmd = 'pgrep -nf "zathura.+--servername ' . v:servername . '"'
	let pid = str2nr(system(cmd)[:-2])
	endif

The command executed here is: pgrep -nf "zathura.+--servername VIM".

How can this command find the correct pid when executed manually from a terminal but find different incorrect pids when executed by VimTeX?

[lervag]

Great, thank you; we are getting close to the core, I think!

Can you now do this:

0. Edit the VimTeX source as necessary. I think you will understand based on our previous discussion, if not, let me know and I'll elaborate. E.g.: add :unsilent echom cmd before lines 135 and 141.

1. vim --servername VIM -u test.vim test.tex

2. \ll

3. Report the following:

   • What is the exact string on your end for the first pgrep command?
   • What is the exact string on your end for the second pgrep command?
   • What is the output of system(cmd) for the pgreps? (Add a line before let pid = ... with :unsilent echom string(system(cmd)).)

[szbernat]

What is the exact string on your end for the first pgrep command?

pgrep -nf "zathura.*/home/bernat/tmp/test\.pdf"

The output of this command is: '' (empty string). This is the same in all 30 executions.

What is the exact string on your end for the second pgrep command?

pgrep -nf "zathura.+--servername VIM"

The output of this command is a seven digit integer which is increasing slightly with each execution. I assume these are pids.