vimtex icon indicating copy to clipboard operation
vimtex copied to clipboard

Make zathura plugin usable on Wayland

Open ftilde opened this issue 4 years ago • 7 comments

This PR changes the zathura viewer to not be a specialization of the xwin template and thus not require or use xdotool. The only functionality of the xwin template that was really used previously was the check for existing windows which used the xwin id. Now we use the pid instead for which there is a function already. In order for that function to robustly, all locations that interact with a zathura process and its arguments (i.e., calls to zathura and the pgrep call in get_pid) use normalize the pdf path to be relative to the current directory. This matches how the latex compiler seems to open the viewer. This could be made even more robust by normalizing all paths to be absolute paths, but I'm not sure how to do that for the zathura instance that is created when starting the compiler. As far as I can tell, the xwin template simply searches for a window with the given viewer name/title (i.e., "Zathura"), however, so the current change is already a step up in that regard.

This would solve #2046.

ftilde avatar Nov 26 '21 12:11 ftilde

The only functionality of the xwin template that was really used previously was the check for existing windows which used the xwin id.

This is not strictly true, because there is also an option to e.g. focus the viewer with inverse search. This relies on xdotool. And a user may apply further customization that relies on xdotool things.

However, I do agree it would be better to simplify these things and avoid using xdotool unless absolutely necessary. So I think you are taking things in the right direction. I think the xwin template should be removed and instead the important functions there should be functions instead of an extra class (or something like that).

Now we use the pid instead for which there is a function already. In order for that function to robustly, all locations that interact with a zathura process and its arguments (i.e., calls to zathura and the pgrep call in get_pid) use normalize the pdf path to be relative to the current directory. This matches how the latex compiler seems to open the viewer. This could be made even more robust by normalizing all paths to be absolute paths, but I'm not sure how to do that for the zathura instance that is created when starting the compiler.

Ah, ok; that answers my separate question. I don't know how to make latexmk use absolute paths when calling the viewer, so it seems you are right to instead adjust from VimTeX side. I would have added a comment to explain why we will not use the supplied absolute path, though.

As far as I can tell, the xwin template simply searches for a window with the given viewer name/title (i.e., "Zathura"), however, so the current change is already a step up in that regard.

Yes and no; there is also the element of timing involved. If we search for a Zathura window just after it was opened, we will usually find the correct window.


Ok, so: I think you are on to something, but it needs more work to avoid regression for some users. In fact, I think it requires a refactoring which may be slightly complicated. But I'm motivated to do it when I get the time.

lervag avatar Nov 27 '21 11:11 lervag

I've now done the refactoring I mentioned. And so we are getting ready to incorporate your suggestions. However, there are some questions first. I would be happy if you could contribute - please see #2271.

lervag avatar Dec 07 '21 09:12 lervag

On 07.12.2021 01:07, Karl Yngve Lervåg wrote:

I've now done the refactoring I mentioned. And so we are getting ready to incorporate your suggestions. However, there are some questions first. I would be happy if you could contribute - please see #2271.

Alright! I've briefly looked over the refactoring. And so far it seems sensible to me. I can unfortunately only help to test this on Linux as well, but I'm happy to do so. Also, I can try to rebase this PR on top of #2271 some time in the next few days and see if any issues arise.

ftilde avatar Dec 08 '21 20:12 ftilde

Alright! I've briefly looked over the refactoring. And so far it seems sensible to me. I can unfortunately only help to test this on Linux as well, but I'm happy to do so. Also, I can try to rebase this PR on top of #2271 some time in the next few days and see if any issues arise.

Great, thanks!

If you do rebase this PR on top, then please do some tests as well. Specifically: your fix relies on keeping the actual command line invocation of zathura the same across VimTeX and latexmk. At zeroth order, I think your fix works. But does it continue to work if the user specifies a different output directory with the build_dir option? If it doesn't, is there an easy way to make it work?

Also, note that one possible simplification would be to overload the .out() method for Zathura. You may need to copy some of the boiler plate code in that case, but feel free to do so. This may reveal a weak point that may need further refactoring from my side.

lervag avatar Dec 08 '21 21:12 lervag

Any updates here?

lervag avatar Apr 28 '22 11:04 lervag

Unfortunately, no. :( Work has continued to be super busy. If someone else wants to take this over, feel free. If not, I definitely plan to come back and finish this up.

ftilde avatar Apr 30 '22 20:04 ftilde

No problem and no rush, take your time :)

lervag avatar Apr 30 '22 21:04 lervag

So, as promised, I just came back to work on this. However, it seems like with the refactorings done in the meantime (especially the pid matching for the zathura instance) it all seems to work flawlessly for me on wayland (sway) with the current master version (including bidirectional position sync between vim and zathura, i.e. vimtex-view etc.). Excellent!

If I encounter any issues in the future, I'll try to fix them, but for now I'm closing this PR now. Thank you for your work!

ftilde avatar Oct 12 '22 08:10 ftilde

Great, I'm glad to hear it works better for you now! :D

lervag avatar Oct 12 '22 13:10 lervag