Vimtex: Add support for neovim

Created on 28 Oct 2015  ยท  44Comments  ยท  Source: lervag/vimtex

Right now vimtex doesn't fully work with neovim. Running latexmk works without problems, but notifying neovim about any errors/warnings is not possible since it doesn't include the clientserver module. neovim instead uses the msgpack-rpc protocol to communicate with clients.

It would be a welcome feature get support for neovim.

Most helpful comment

For windows neovim vimtex users, there is a workaround using neovim's python API:

  1. Save the following script to something like C:\python_scripts\connect_to_nvim.py

    import neovim
    import os
    import sys
    
    nvim = neovim.attach('socket', path=os.environ['NVIM_LISTEN_ADDRESS'])
    nvim.command(r':e +{1} "{0}"'.format(sys.argv[1], sys.argv[2]))
    
  2. Specify in SumatraPDF's "Settings -> Options -> Set inverse search command-line"
    pythonw C:\python_scripts\connect_to_nvim.py "%f" %l

  3. Set system variable NVIM_LISTEN_ADDRESS to something like \\.\pipe\nvim-1234

Note that you might need to restart :VimtexCompile after having done the first backward search (maybe the file name changes a little?).

All 44 comments

Thanks for opening the issue! I'm considering to use neovim myself these days, but I haven't gotten there yet.

Do you know if there are more issues than the callback feature? If so, I think we should create a task list in your original post.

I've understood that the msgpack-rpc protocol is supposed to be more powerful, but do you know if there is a similarly easy way to communicate with a server as the clientserver functionalit in Vim? That is, in Vim I can do this:

vim --servername NAME --remote-expr 'vimtex#latexmk#callback()`

How would I do the same thing in neovim using msgpack-rpc? I don't really like the idea of creating a dedicated script (ruby/python) just to do this simple thing.

Another thing: Since neovim allows detached subprocesses, I could perhaps utilize this. Alternatively, I could use the terminal in neovim to run the latexmk process. Ideas and input is very much welcome here!

Indeed, for such a simple thing, neovim job control API would be sufficient (but I have never used it by myself therefore can't help you here): https://neovim.io/doc/user/job_control.html

Here is an example that shows how to use it: https://gist.github.com/tarruda/1b5010531bb6ae7382a4

Beside from that I don't think any further changes should be necessary. neovims full help page: https://neovim.io/doc/user/nvim.html

I just want to pop out to say that I am using vimtex right now with neovim. I am pretty sure that I am missing features, but for me is already good enough. I have sync it with Zathura and seeing the changes in the pdf after saving the file in neovim is all I require.

Just in case somebody comes to this issue thinking that the plugin cannot run in neovim. Hope it helps, cheers.

@sschaef I've added a comment at the neovim issue #1750. I think there might be hope that neovim gets a similar functionality to vim with --remote-expr, which would make it easy to add support for neovim in vimtex. I'll leave this issue unresolved while waiting for an update at the neovim side.

An alternative while waiting for neovim to return compatibility with Vim is to use neovim-remote. I think this should work out of the box if one sets g:vimtex_latexmk_progname = '/path/to/neovim-remote' (or if it is in $PATH, then it should suffice to just use the basename).

Setting g:vimtex_latexmk_progname = 'nvr' is not sufficient because:

  1. view.vim#L336 and view.vim#L378: the PDF viewer (zathura in this case) is always called with callback to v:progname.
  2. latexmk.vim#L421: has('clientserver') is currently false in nvim.

I've tried dirty-patching these code and it worked very well, just like in the original vim.

Thanks, @hexchain. I've pushed an update that should fix this for you. Could you please verify that it now works without any custom patches?

Thanks @lervag, it works!

Great, thanks for letting me know! I think this will be the current solution for neovim until neovim is updated to handle the remote options (which, IMHO, should be reimplemented!). I'll update the docs with a comment in the meantime (will do it when I get some time).

In the mean time: Merry christmas, everyone! :)

I am using https://github.com/rogual/neovim-dot-app under osx together with vimtex and skim. I have installed neovim-remote, as well.

Forward-search works. However, backwards-search not (Cmd+Shift+Left Mouse Click).

I have started the neovim-gui via:

$ NVIM_LISTEN_ADDRESS=/tmp/nvimsocket gnvim

Following test works:

$ /Users/hotschke/.local/bin/nvr --servername "/tmp/nvimsocket" --remote-silent +120 "$PWD/mydocument.tex"

But the settings in Skim.app apparently are not completely correct:
screen shot 2016-01-08 at 09 09 37

PDF-TeX Sync support:
Preset: Custom
Command: /Users/hotschke/.local/bin/nvr
Arguments: --servername "/tmp/nvimsocket" --remote-silent +"%line" "%file"

Does anyone know what is incorrect?

I'm sorry, but I can't help here. I don't have OSX and don't know what is wrong with your settings. They seem right, though. Do I understand correctly that the corresponding command with normal Vim works?

Everything works as expected with MacVim.

I am surprised that the command line test 'opening my tex document with nvr at a specific line' works and also uses the right editor instance. Only Skim.app does not work. Unfortunately, I haven't figured out to get Skim.app to report what is going on.

What happens? You could try to remove the remote part, so that nvr opens a new instance. If it doesn't even do that, then at least you know there is a problem with starting nvr from Skim...

Just to be clear, the environment variable NVIM_LISTEN_ADDRESS is not relevant for ordinary vim/macvim. Skim.app contains default values for MacVim which are as I said fine.

screen shot 2016-01-08 at 14 34 34

I am not sure whether this has something to do with environment variables under OSX (e.g. http://superuser.com/questions/476752/setting-environment-variables-in-os-x-for-gui-applications).

BTW, nvr always adds --remote.

$ nvr -h
usage: /Users/hotschke/.local/bin/nvr [arguments]

Helper tool for nvim that provides --remote and friends.

All unused arguments will be implicitely fed to --remote-silent.
Thus the following two lines are equivalent:

$ nvr --remote-silent foo bar quux
$ nvr foo bar quux

The Arguments field can therefore be simplified to

 Arguments: --servername "/tmp/nvimsocket" +"%line" "%file"

Also dropping the --servername option does not open a new nvim instance in a terminal.

Using gnvim directly opens a always new neovim.app.

screen shot 2016-01-08 at 14 40 40

It seems to be an issue with nvr.

I guess I hope for someone with OSX who has managed to get it work. Thanks for your help.

@Hotschke No problem. I hope someone comes along that can help contribute a solution to this problem.

Note that the neovim-remote workaround is broken by recent commits to neovim-remote https://github.com/mhinz/neovim-remote/issues/5. The most recent working commit (for vimtex purposes) in neovim-remote is d206e65548e6a8f95300f8fb7ecaa0a162f90cd5.

I see. Do I understand correctly that this could be fixed if I change the + arguments into -c arguments in the remote call setups?

Yep, you figured that out a lot quicker than I did!

Heh, nah, I'm cheating: I was reading the issue at neovim-remote that you linked to. :)

Thanks for opening a new issue for this. I'll look into it. I'll make sure to test that the change does not break anything, and if it doesn't then I should be able to ship it pretty soon.

@nacnudus Could you please test if the recent update to neovim-remote fixes the issue?

It's working. Brilliant :)

Great!

By the way: I've reconsidered my resolve to keep this issue open until full support for neovim is provided through an update on the neovim side. Since I've already decided that I won't implement a custom solution on the vimtex end, and since neovim-remote seems to work very well, I've decided to close this issue as resolved. This makes the list of open issues slightly less intimidating...

For me neovim backward search does not work.
minimal vimrc:

set nocompatible

let mapleader = "รค"
let maplocalleader = "รถ"

" force ft=tex on every *.tex file
autocmd BufRead,BufNewFile *.tex set filetype=tex
autocmd BufRead,BufNewFile SConstruct set filetype=python

let plugin_root = '~/.config/vim/vim/plugged'

if has('nvim')
  let plugin_root = '~/.config/nvim/bundle'
  let g:vimtex_latexmk_progname = 'nvr'
endif

" Load Vimtex
let &rtp  = plugin_root . '/vimtex,' . &rtp
let &rtp .= ',' . plugin_root . '/vimtex/after'

filetype plugin indent on
syntax enable

" Vimtex options go here
let g:vimtex_view_method = 'zathura'

From standard vim this works fine.
I have neovim-remote installed and nvr is in $PATH.

Weird... If I replace nvr with the complete path it works.

โฏ which nvr
/home/franz/bin/nvr

:echo $PATH returns /home/franz/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/games/bin so nvr should be enough. Is this a neovim-bug?

This is strange. What happens if you just write :!nvr? Or :!echo $PATH?

Btw, instead of an autocmd, you can use let g:tex_flavor = 'latex'. You can also remove the python autocommand from the minimal vimrc. :)

:!nvr results in command not found.
:!echo $PATH does not contain ~/bin.
But I think I found the issue: I am running zsh. As soon as I run it from bash (su -s /bin/bash -- franz) everything is as expected.
Btw.: Both neovim and vim show this behaviour. Is there something I miss in my vimrc?

The (to you probably obvious) workaround is set shell=bash. But I think it should work with shell=zsh, too. I will open an issue for neovim.

I think there might be some inconsistensies in your shell settings. Is zsh your login shell? You can see this from getent passwd $LOGNAME (in my case, it shows (among other things) /bin/zsh).

I also use zsh, and my Vim shows /bin/zsh when I do :set shell. No need to specify shell.

Ok. Good to know. At least we know it's not related to vimtex. :)

I am not sure if this is still relevant, but I got backwards search working using Skim.app and NeoVim in a terminal. @Hotschke was definitely on the right track, for me the following setup works:
screenshot 2016-07-05 14 59 09

This is with NeoVim 0.1.4 running in iTerm2 Build 3.0.1 and Skim Version 1.4.18 (92). My NeoVim Remote has version 1.2.2. In addition nvr is in my $PATH but using the full path /usr/local/bin/nvr works as well.

Thanks for the info!

I can confirm that now the backwards search works for me as well:
nvim (v0.1.5-471-g51fe40a) in iTerm2 (v3.0.4), nvr (v1.2.2), skim (v1.4.19 (93)) and vimtex (7234c5a, Jun 28 2016).

1) However, for me the plus notation still does not work. But the suggested mapping by mhinz https://github.com/mhinz/neovim-remote/issues/3#issuecomment-170302148 works:

 Arguments: --servername /tmp/nvimsocket -c %line "%file"

2) Also for gnvim (neovim-osx-gui) it does not work.

Anyhow glad to see that it seems to work for command line instance.

As far as I can tell I still have to remove the check for has('clientserver') in latexmk.vim to get it to work with neovim-remote?
At least that is how I got it working.

That's strange. I assume this means you also got the warning?

Is this the case in general for other neovim users? I was not aware that neovim has removed the clientserver flag (I thought it was always enabled).

Yes I got the warning. I have the newest versions of both vimtex and neovim on my macbook.

I can confirm that NeoVim shows the vimtex: Can't use callbacks without +clientserver warning on every startup, however with let g:vimtex_latexmk_progname = 'nvr' in my nvim/init.vim I do not have any further issues. Patching latexmk.vim is not necessary for me.

@jdoerrie If that's the case, then the callbacks should not activate. This warning is followed by let g:vimtex_latexmk_callback = 0. I'm pushing a minor update to check for either clientserver or nvim, which should fix this.

Can confirm that both forward and backward search work for me, using vimtex, neovim-remote and qpdfview. No need to patch anything.

Thanks, good to hear.

For windows neovim vimtex users, there is a workaround using neovim's python API:

  1. Save the following script to something like C:\python_scripts\connect_to_nvim.py

    import neovim
    import os
    import sys
    
    nvim = neovim.attach('socket', path=os.environ['NVIM_LISTEN_ADDRESS'])
    nvim.command(r':e +{1} "{0}"'.format(sys.argv[1], sys.argv[2]))
    
  2. Specify in SumatraPDF's "Settings -> Options -> Set inverse search command-line"
    pythonw C:\python_scripts\connect_to_nvim.py "%f" %l

  3. Set system variable NVIM_LISTEN_ADDRESS to something like \\.\pipe\nvim-1234

Note that you might need to restart :VimtexCompile after having done the first backward search (maybe the file name changes a little?).

It would be helpful if you could open a new issue for this where you properly describe the context (e.g. refer to this issue) and state what you think should change. It seems you might be proposing something that should be added to the docs.

Note: I would be happy to discuss most anything, but please open a new issue instead of bumping a more than two year old issue.

There is nothing really to report on the vimtex side; it works perfectly :)
There is already an outstanding neovim issue https://github.com/neovim/neovim/issues/1750 though. Once it is resolved, one wouldn't need my workaround any more.

This discussion thread is shown by search engines when you look for "vimtex backward search neovim windows", so I hope that my previous comment would be useful for people searching how to setup such an integration.

Ok, thanks! That makes sense. :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lervag picture lervag  ยท  3Comments

carloabelli picture carloabelli  ยท  3Comments

LuxGiammi picture LuxGiammi  ยท  3Comments

vsbuffalo picture vsbuffalo  ยท  3Comments

siemdejong picture siemdejong  ยท  5Comments