Inverse search fails on NixOS due to missing runtime path when executing Vim binary directly

[briancarbone]

On NixOS, vimtex procures an executable path like /nix/store/rbpdnv0lxk7y6vz1426x5cm9rbr4bx96-vim-full-523f9f5/bin/.vim-wrapped as in this excerpt from :VimtexInfo:

cmd_start: zathura  -x "/nix/store/rbpdnv0lxk7y6vz1426x5cm9rbr4bx96-vim-full-523f9f5/bin/.vim-wrapped -T dumb --not-a-term -n -c \"VimtexInverseSearch %{line}:%{column} '%{input}'\"" --synctex-forward 1:1:'/home/brian/math/velleman/main.tex' 'main.pdf'&

Also on NixOS, Vim is run via a wrapper script which provides vimrc as an argument (via -u), as seen here:

[~]$ cat $(readlink `which vim`)
#! /nix/store/00zrahbb32nzawrmv9sjxn36h7qk9vrs-bash-5.2p37/bin/bash -e
exec "/nix/store/rjb5y9kx99n13pr74n8fahhfh5lgr0r7-vim-full-651edf3/bin/vim" -N  -u '/nix/store/9q2lf8jfdhrad953kbs6saq6j75dfhsd-vimrc'  "$@"

It seems .vim-wrapped is the binary and not the script, but it prevents inverse search from working correctly because plugins aren't loaded without vimrc containing the runtime path.

Setting g:vimtex_callback_progpath to exepath(v:progname) fixes the issue. Perhaps that should be the default method vimtex uses to obtain the vim command (rather than just v:progname). That would need testing on non-NixOS systems.

[lervag]

Setting g:vimtex_callback_progpath to exepath(v:progname) fixes the issue. Perhaps that should be the default method vimtex uses to obtain the vim command (rather than just v:progname). That would need testing on non-NixOS systems.

I'm probably daft, but what's the difference for the Zathura command when you use either of those? That is, from :VimtexInfo, what does the cmd_start look like with and without exepath()?

[briancarbone]

With: /run/current-system/sw/bin/vim which is correct; that's a symlink to the wrapper script which executes the binary with -u vimrc.

Without: /nix/store/rbpdnv0lxk7y6vz1426x5cm9rbr4bx96-vim-full-523f9f5/bin/.vim-wrapped which is the binary (not the wrapper script).

[lervag]

Huh, that's very strange. It doesn't really make sense to my why exepath(v:progname) should resolve to a different target than v:progname.

So, from your info so far I gather this:

/run/current-system/sw/bin/vim    The wrapper script
/nix/store/rjb…/bin/vim           The actual Vim binary
/nix/store/rbp…/bin/.vim-wrapped  A symlink to ↑ (the binary)

I would expect which vim to return /run/current-system/sw/bin/vim, is that right?

Edit: Or, no, I think I am getting the above wrong. It would be useful if you could help me understand by listing and explaining the different binary files, wrappers and symlinks here.

[lervag]

In my experience, the current default more or less "just works", and as I don't 100 % understand what is happening I am afraid that changing the default may break things on some systems. Further, people like you who use NixOS are very likely quite advanced users who knows your way around systems like this - case in point: you solved your own issue already. So, to be honest, I don't feel very tempted to change the default here.

I might reconsider if I properly understand what is happening here in your case.

[lervag]

Ok, so:

• v:progname is the name by which Vim is invoked. If you create a symlink, e.g. ln -s /usr/bin/vim myothervim, then running ./myothervim means v:progname becomes myothervim.
• exepath(expr) will attempt to resolve expr against $PATH. In your case, the /nix/store/.../vim binary is probably not in $PATH, whereas /run/current-system/sw/bin is in $PATH. This explains why it makes things work for you.

So, if I made this change, it would most likely continue to work for most people in general. But it might break things if someone is doing something strange with symlinks - and I've learned to never trust what people are doing. Thus, I still think I want to avoid the change.