xwin id for files of the same name in different paths not correctly identified

[stupidus89]

Edit

Below is just my original issue. The actual issue is described in #947 (comment).

Explain the issue

I am not sure if this is actually an issue with vimtex, or if it is an issue with neovim or neovim-remote.

I am using the following script to run neovim:

#!/bin/sh

ID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
socket=/tmp/nvim-$ID

function finish {
    zatpid=$(ps aux | grep zathura | grep $socket | awk '{print $2}')
    kill $zatpid
}

nvr --servername $socket --remote-silent +":call Texstartup()" $1

trap finish EXIT

The Texstartup() function just does the following:

function! Texstartup()
    Neomake latexmk
    autocmd BufWritePost *.tex :execute "normal \<Plug>(vimtex-view)"
    :execute "normal \<Plug>(vimtex-view)"
endfunction

The Neomake command just runs latexmk in continuous mode in the background (see below).

Expected behaviour:

When I run the script on a .tex file, both forward and backward search work with zathura. This actually works most of the time.

Occasionally observed behaviour:

Sometimes, backward search does not work. This problem usually occurs, when I use the script above multiple times and/or for different files. Once it stops working for a certain file, no matter how often I try to run the script on that file again, it will not work, until I reboot my machine.

I noticed there is a difference in the output of <Leader>li between when it works and when it does not.
If it works, I can see the following:

 viewer: Zathura
    xwin id: 16777219
    process: 
      pid: -
      cmd: zathura -x "nvr --servername /tmp/nvim-GXAG2Vgmt8SCQdzAF2KaRw3qqQ7UWWTt --remote +\%{line} \%{input}" --synctex-forward 1:1:'/path/to/main.tex'  '/path/to/main.pdf' >/dev/null 2>&1 &

In case, it does not work:

viewer: Zathura
    xwin id: 35651587
    cmd_forward_search: zathura --synctex-forward 1:1:'/path/to/main.tex' '/path/to/main.pdf'

What is the difference between cmd and cmd_forward_search?

Minimal vimrc file

The vimtex related options in my neovim config:

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

The Neomake command from above:

let g:neomake_tex_latexmk_maker = { 'exe': 'latexmk', 'args': ['-pdf', '-pvc'] }

My .latexmkrc:

$pdflatex = 'pdflatex -interaction=nonstopmode -shell-escape -synctex=1  %O %S';
$pdf_previewer = 'zathura --synctex-forward %O %S &';

neovim 0.2.0
neovim-remote 1.8.0
vimtex from github

[stupidus89]

I looked a bit through the source code and I found that lines 99-106 in autoload/vimtex/view/common.vim seem to decide between calling the start function or the forward_search function depending on the existence of xwin. So I assume, that this xwin id might get stored somewhere or somehow persist between different instances of neovim or zathura.

After digging some further I found, that the xwin id seems to depend on the filename. So if I open /a/file.tex with my script, zathura will open /a/file.pdf and assign a certain xwin id. After that opening /b/file.tex, will cause vimtex to use xdotool to get the xwin id, (using only the filename, not the path?) and find an existing xwin id and then call zathura with the forward_search function.

So, I think there is some problem with the s:xwin_template.xwin_get_id() function.

EDIT: I just tried to reproduce this with a simple example:

/tmp/a/file.tex

\documentclass{article}
\begin{document}
Hello!
\end{document}

I then copied this file to /tmp/b/file.tex.

After compiling the files, I open them in neovim in two different terminal windows. If I call <Leader>lv on the first file it reports 46137347 as the xwin id. Then I call <Leader>lv for the other file (in the other terminal), it reports the same xwin_id, even though the newly opened zathura window has a different id (I checked via xprop).

[lervag]

Yes, this is actually a problem I am aware of. I tried once to find a good solution, but unfortunately I was not able to. I don't quite see how to solve this, because the full paths of the files are not available when searching for the window ids. Thus, when we have two files with the same name, I have not found a reliable method of getting the correct window id.

Since the last time I worked on this, I have become better at creating good tests, and so I will make test files for this issue to replicate the problem again. I will also see if I can find a better way to handle it. Perhaps I can find useful information that can be parsed from /proc/PID or similar.

Just to be sure, your final edit indicates that your entire problem has to do with finding the correct window ID when the pdf files have the same basename. Is this correct?

[lervag]

Just to clarify one thing: The backward search is only available if you have started Zathura with the proper settings, e.g. -x "nvr --servername /tmp/nvim-GXAG2Vgmt8SCQdzAF2KaRw3qqQ7UWWTt --remote +\%{line} \%{input}". Note that this option indicates a specific neovim servername that is unique to a single instance of neovim. Thus, if you open a viewer in neovim, then close the neovim session and start a new one, you may end up with the situation you describe where backward search no longer works.

[stupidus89]

Thank you for the reply!
Yes, my entire problem boils down to finding the correct window ID for files with the same name. I just was not aware of this, when I opened the bug report. I should probably change the title and my first post, to make it more clear.

I am aware, that backward search only works, if zathura is started correctly. That's why I always close zathura when I close neovim, so the sessions don't get mixed up. It's only a problem if there are different files with the same name.

As an idea: Could it be possible to use the ps output and search for the v:servername variable there to get the PID of the correct zathura process, and then use xdotool search --pid to find the window ID? To get the PID, you could use something similar as I use in the trap function in my script in the first post.

[andymass]

This pretty much implements @stupidus89 's suggestion. Completely untested!

andymass/vimtex@b25e7b8

[stupidus89]

I pulled your patch and did a quick test. It seems to work with my files. Thank you.

[lervag]

Ok, I've implemented this based on @andymass's implementation. I used a different regex to instead match the target pdf file. I've tried to escape the necessary characters.

I've also filtered the resulting xwin_ids so as not to match any id that is connected to a different buffer. This helps in case one has two different files open in the same Vim instance that has the same file name. I think this should mostly work.

However, this feature is difficult to test in a reliable manner, so please let me know how this works.

[stupidus89]

I cannot confirm that the new version works. I used the simple minimal example with /tmp/a/file.tex and /tmp/b/file.tex. I opened the files in two separate terminal windows. For the second file, it still gets the same xwin_id as for the first file and then uses cmd_forward_search instead of cmd.

[andymass]

@lervag, just curious, what was the reason to pgrep the filename instead of the servername to find the zathura pid? I think this can't work because no pid will ever be found for that filename, and so xdotool will just use the main.pdf part, as before. Plus, once vimtex detects a zathura with a different servername, backward/inverse search won't work.

[lervag]

@andymass
The reason, which might have been wrong, was that I don't want to connect the current vimtex instance to a zathura viewer that has a different document opened. This works if you use a single Vim instance instead of two terminals. As you say, it does detect a zathura with a different servername, but I don't think this is quite so crucial, as almost everything should still work. However, I recognize that I should require that the version that uses the pid never allows to match viewers if no pid is found. I'm pusing an update right now.

@stupidus89
Please try again with the latest version. As said above, this does still "break" backward sync if you have a persistent zathura session between Vim sessions, but I find this more "appropriate" than creating a new zathura instance. If you miss backward sync, you only kill the current zathura and view again.

Note one thing, though: This might not work as expected if the viewer is started from latexmk. In this particular case, it might work better with the servername as the grep point...