Vimtex: Consider supporting WSL vim with Windows TeX Install

[sskeirik]

Question

Would you be willing to accept a patch to let a user install a (neo)vim binary on the WSL side but utilize a TeX install on the Windows side?

I have started development work, but I would probably need a little help to make everything works right and to double check that my vimscript is idiomatic.

WSL Background Reference (In Case Needed)

On a Win10 system, the WSL feature allows the user to create a special directory which is tagged as a Linux distribution, i.e., this directory will become the root of a Linux installation (similar to how the chroot command works on Linux). Let's call it the Linux root.

By invoking a special command from the Windows command line, one can execute a (completely vanilla) Linux binary whose CWD will be some subfolder of the Linux root and where the filesystem in which the binary executes will be the entire subtree under Linux root.

Win10 also provides WSL <-> Win10 interop. What this means is:

1. All Linux distributions can automount the Win10 file system (typically as a subdirectory of /mnt)
2. All Linux binaries can directly execute Win10 binaries. The Win10 binary is referenced by its Linux path (i.e., under the Win10 FS mount point /mnt/c). All arguments passed to the Win10 binary invoked this way are sent AS-IS; no modification is done. The CWD of the Win10 process is inherited from the Linux process by the following mechanism:
   
   
   
   • if the CWD of the Linux process is a subdirectory of the Win10 FS mount point, the CWD of the Win10 process will the corresponding Win10 FS path
   
   
   • otherwise, the CWD of the Win10 process is some directory chosen by the system
   
   
3. Currently, Win10 binaries cannot safely access files under Linux root (though this will change in a version of Win10 coming soon).
4. Win10 provides a wslpath binary with the same arguments as cygpath for WSL <-> Win10 FS path conversion

Together, points (1)-(4) imply that, if we are careful, we can execute Windows binaries from the Linux side in a way that is almost completely transparent to the user. In particular, we can use a WSL installed vim and call latex and PDF viewer binaries on the Win10 side.

Rationale

Of course, in this whole discussion, the obvious question is: why do all this work?

• Since TeX installs are quite large, keeping a single copy saves space.
• It simplifies any build issues that could arise from having multiple, inconsistent TeX installs on the WSL side and Win10 side.
• The WSL environment provides the simplicity of a Linux dev environment but with working graphics/wifi/etc... drivers everywhere (especially important for laptops).
• AFAICT, WSL-based tooling is growing in popularity and shows no signs of slowing down.

Work Items Needed

1. Add a configuration variable for WSL mode, e.g., g:vimtex_wsl_mode plus documentation
2. In WSL mode, assert our current working directory is beneath the Win10 FS mount point and error out if not
3. In WSL mode, executing a Win10 binary from the WSL side will not automagically append .exe to binary names; thus, fixed binary names like bibtex, kpsewhich will need code to append the .exe suffix
4. In WSL mode, all paths to filenames will need to be converted (e.g. by wslpath) for use with the Win10 TeX install, PDF viewers, etc...
5. In WSL mode, due to a bug in the Vimscript executable function in Neovim (possibly also on Vim, but I haven't checked), some of the executability checks will need to be removed. According to my tests, running executable when providing an absolute path in the Win10 side, e.g., executable(/mnt/c/Program\ Files/SumatraPDF/SumatraPDF.exe) returns 0 when 1 is expected. I will file a bug against Neovim soon for this issue. This stopgap measure will not be needed once the bug is fixed.

Notes

In the next version of Win10 that supports Win10 binaries safely accessing files under Linux root, more possibilities open up:

1. If desired, the check in (2) can be safely removed so that directories under Linux root are supported.
2. If (6) is adopted, then (4) will need different behavior depending on whether the CWD is under Linux root or in the standard Win10 FS.

[sskeirik]

Actually, the more I think about this issue, the more I wonder if this is the right approach, because there are actually many possibilities. I'm not sure if this additional complexity is worth it for vimtex; the community of users might be too small.

Other possibilities:

1. Moving LaTeX installation and PDF viewer to WSL side and just using an X sever on Win10 side (all on WSL option).
2. Wrapping latex binaries directly for path conversion, etc... This would permit them to be used directly on the command line and opens the possibility of using more languages besides Vimscript. It also avoids bugs in the Vimscript implementation in Neovim. In this case, the TeX install could be on either WSL or Win10 side (hybrid WSL/Win10 option).
3. Installing a vim on the Win10 side which would be used for LaTeX editing (at least) and have a separate vim on the WSL side for Linux development purposes (all on Win10 option).

(1) and (3) are definitely possible, but both feel non-optimal in that they require extra software to be installed.

(3) has the advantage that the GUI will be lighter weight as it is Win10 native.

(1) in particular has the disadvantage that Windows input method editors (IME)s don't seem to work well on X servers for Windows.

It is clear that I need to go back and consider this issue more carefully; I'm going to close it for now, but feel free to offer any comments if you have them.

[lervag]

Would you be willing to accept a patch to let a user install a (neo)vim binary on the WSL side but utilize a TeX install on the Windows side?

I would definately be willing to consider such a patch!

My main difficulty regarding vimtex on Windows is that I don't use it on that platform myself. As such, it is difficult to properly maintain it, and I partly rely on the community to help locate and fix problems.

If anyone would be both willing and able in improving the experience on Windows, then I would of course be happy to assist and accept PRs!

Of course, in this whole discussion, the obvious question is: why do all this work?

I agree this is a good question. I would think it should be easy to install both a full TeXlive distribution and good PDF viewers inside the WSL. And if so, it seems one should be able to get a good LaTeX-editing experience on Windows through WSL without any major changes (this is your point number 1, I think). I don't see many downsides here, except perhaps _"Currently, Win10 binaries cannot safely access files under Linux root (though this will change in a version of Win10 coming soon)."_.

At the same time, if some relatively small changes in vimtex would improve the experience in general on Windows and WSL, then I'm all for it!

[Konfekt]

This endeavor is over my head, but for what it is worth

if has('win32') || (has('unix') && exists('$WSLENV'))
  let g:vimtex_view_general_viewer = 'SumatraPDF.exe'
  let g:vimtex_view_general_options_latexmk = '-reuse-instance'
endif

works fine under Windows and under WSL when Vim is started in the WSL home directory ~ (as opposed to %USERPROFILE%, where the shell starts in by default).

However, it seems that client-server capabilities are disabled (perhaps because WSL does not have built-in support for X11) and therefore backward search does not work.
Also, forward search does not work because while SumatraPDF opens fine a file file.pdf in \\wsl$\..., the forward search in SumatraPDF itself does not find the corresponding source file file.tex in \\wsl$\....

[Konfekt]

Perhaps above setup is worth a mere comment in the docs regarding WSL support. The access to files in WSL via the network share \\wsl$ is fairly recent, since Windows 10 Version 1903, see here.

[Konfekt]

Regarding reusing the TeX installation on Windows, while this saves disk spaces (which is cheap) and reduces maintenance (though TeX is mature), it causes a big slow down, even more so on WSL2, see here.

Therefore, as much as possible should be installed in WSL itself. The pandoc documentation gives instructions for a minimal TeXLive system. See here for a discussion. On OpenSUSE, this can be achieved by

sudo zypper install 
texlive-collection-fontsrecommended
texlive-latexmk
texlive-scheme-basic

[lervag]

I would be happy to add some text to the docs, but it would be helpful to get a suggestion on what I should add. Either a PR or something verbatim in this thread.

[clason]

@Konfekt Even on openSUSE (which I'm using at work), you'd be much better off just installing vanilla texlive. (Distributions add an -- in this case -- unnecessary level of indirection and update delay.) Just install wherever and put $TEXLIVE_DIR/YEAR/bin/ARCH in (front of) your path.

_Not_ installing a full TeX distribution will just lead to headaches down the road, so I'd strongly recommend not making this an official recommendation. My suggestion would be to just write "and follow the instructions for installing texlive [link] for Linux".

[Konfekt]

Thanks for these considerations. I updated the documentation accordingly.

[lervag]

Thanks for the input and the PR! Appreciated!