restore --remote (+clientserver)

[justinmk]

AFAICT there is no reason we should not restore these Vim command line options:

   --remote <files>▸    Edit <files> in a Vim server if possible
   --remote-silent <files>  Same, don't complain if there is no server
   --remote-wait <files>  As --remote but wait for files to have been edited
   --remote-wait-silent <files>  Same, don't complain if there is no server
   --remote-tab[-wait][-silent] <files>  As --remote but use tab page per file
   --remote-send <keys>▸Send <keys> to a Vim server and exit
   --remote-expr <expr>▸Evaluate <expr> in a Vim server and print result 

What is the equivalent of these options in the current state of Neovim? cc @tarruda

[xu-cheng]

👍 I really need this for synctex.

[tarruda]

What is the equivalent of these options in the current state of Neovim? cc @tarruda

Any of vim remote-* commands can be easily emulated via msgpack-rpc, here's a quick and dirty python implementation:

#!/usr/bin/env python
import click, re, sys
from neovim import attach


IP_ADDR = re.compile(r'^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(?:\:\d{1,5})?$')


@click.command(context_settings=dict(allow_extra_args=True))
@click.option('--address')
@click.option('--send', default=None)
@click.option('--expr', default=None)
@click.option('--tab/--no-tab', default=False)
@click.option('--silent/--no-silent', default=False)
@click.pass_context
def main(ctx, address, send, expr, tab, silent):
    if IP_ADDR.match(address):
        args = ('tcp',)
        kwargs = {'address': address}
    else:
        args = ('socket',)
        kwargs = {'path': address}
    try:
        nvim = attach(*args, **kwargs)
    except Exception as e:
        if not silent:
            print >> sys.stderr, e.message
        sys.exit(1)

    if send:
        nvim.input(send)
    elif expr:
        print nvim.eval(expr)
    else:
        files = ctx.args
        if not files:
            print >> sys.stderr, 'Need at least one file to edit'
            sys.exit(1)
        cmd = 'tabedit' if tab else 'edit'
        for f in files:
            nvim.command('{0} {1}'.format(cmd, f))


if __name__ == '__main__':
    main()

The question is, do we need to bundle this functionality in the nvim executable? IMO it would be better to have a general purpose shell utility and distribute it with nvim.

[justinmk]

With something like #1446 we wouldn't need python. I would say it should be bundled

[aktau]

With something like #1446 we wouldn't need python. I would say it should be bundled

Yea, ideally it should just work without fussing and (as has been recently shown by @justinmk) getting python to work is not always fuss-free. So a VimL implementation of this functionality would, in my mind, show the true power of nvim.

[jalvesaq]

Just an idea: Perhaps Neovim could ship with a small application written in C called nvimclient that would do only one thing: get the environment variable NVIM_LISTEN_ADDRESS and send a message to that address. Then, it would be easy to implement SyncTeX backward with PDF viewers like Zathura and Sumatra which accept a command line argument to setup the backward search. If the pdf viewers are started by nvim, they will inherit its environment variables. The nvimclient could also accept the --servername argument for compatibility with Vim plugins that use the 'clientserver' feature.

[justinmk]

Why a separate program?

[jalvesaq]

The main reason to have a separate program is because it would be quicker to launch, but I am not sure if this is necessary since nvim is already lightweight. Another reason is that when nvim finds the environment variable NVIM_LISTEN_ADDRESS it listens on the address while the nvimclient would write to it. But this is not a good reason too because the arguments --remote-expr etc will turn nvim into a client. One third reason is that the command line to call nvimclient would be simpler than calling nvim. For example, it could be

nvimclient 'call MyFunction("text here", 0)'

instead of

nvim --servername /tmp/nvimCg4gH/0 --remote-expr 'MyFunction("text here", 0)'

But, at the end, I am sure that any implementation will be good and plugin developers will adapt to whatever decision Neovim developers make.

[tarruda]

The main reason to have a separate program is because it would be quicker to launch, but I am not sure if this is necessary since nvim is already lightweight.

@jalvesaq as long as we only run the code necessary to connect and send the message(no need to source vimrc or any other scripts), the startup would already be fast since it's very likely that the code is already cached by the operating system.

Another reason is that when nvim finds the environment variable NVIM_LISTEN_ADDRESS it listens on the address while the nvimclient would write to it.

We need to change that, now that we have a serverlisten function, it would be better to only listen on a socket when explicitly started by the user or a plugin.

Honestly, I don't think we need to reimplement the --remote-* flags from vim, there's no need to maintain compatibility with command line options. With the changes introduced by @splinterofchaos in #1446, rpcrequest/rpcnotify can already control remote nvim instances in any way imaginable. We just need a rpcconnect function to connect to an already running instance(rpcstart will spawn a new instance).

With a vimscript command library wrapping rpcrequest/rpcconnect, sending a command to another nvim would be as simple:

nvim -u NONE +'RemoteSend /path/to/socket command'

[jalvesaq]

It's good to know that only rpcconnect is missing!

[Moelf]

As you guys are talking about, is there a way to make neovim + Skim backward search working?

[justinmk]

I don't know what Skim is.

[jalvesaq]

Skim is a PDF viewer (Mac OS X) with SyncTeX support. For those who don't know, SyncTeX is a system of synchronization between a LaTeX text editor (which might be Vim or Neovim) and the PDF viewer. We can both click in the PDF to jump to the corresponding line in the text editor and issue a command in the text editor to jump to the corresponding place in the PDF. That is, we need a way of sending a message from the PDF editor to Neovim. In Vim, the 'clientserver' is used for SyncTeX.

I implemented SyncTeX support for Rnoweb (LaTeX + R) files in Neovim (Nvim-R), but in order to do this, I created a C application that runs a TCP server (run as a Neovim job) and another C application that I called nvimrclient which sends messages to the server. The PDF viewer must be configured to run the nvimrclient.

[justinmk]

I created a C application that runs a TCP server (run as a Neovim job) and another C application that I called nvimrclient which sends messages to the server.

A very urgent goal for us is to make nvim serve this purpose out of the box, i.e., it should be a client of itself. #3119

The legacy --remote feature would be implemented as a special case of this general capability.

[lervag]

Agreed, I also would very much like this feature in neovim. I'm developing vimtex, and I am using callbacks with the following syntax in vim:

vim --servername NAME --remote-expr "function-name()"

I both know and understand that I can utilize external scripts through python and ruby (and I guess other languages), but I think the "old" method is very convenient for my particular need.

I am currently working on neovim support, see #262, and if the legacy feature was added to neovim, then the changes required in vimtex would be minimal.

[mhinz]

As long as there's no other solution, here a wrapper script that handles --remote and friends: https://github.com/mhinz/neovim-remote

[justinmk]

Awesome. That makes it straightforward for someone to use as a reference for implementing in C.

[lervag]

Thanks, @mhinz!

[mkoskar]

Doing

nvr --servername $TMPDIR/nvim --remote-tab /tmp

or

nvr --servername $TMPDIR/nvim -c 'tabedit /tmp'

given that /tmp is real directory tab is not opened. I can see the buffer listed though. I know that directories are treated specially, and in this case I've disabled netrw but just for sake of consistency it should behave the same as when doing :tabedit /tmp from inside nvim when actually new tab is created. Could this be related to the fact that autocommands are not triggered (as I've learned from nvim-remote README)?

[lluixhi]

What's the status on this bug exactly? Are we going to stick with the status quo or bundle a client program for compatiblity with vim?

I'm curious because I'm considering packaging https://github.com/mhinz/neovim-remote, and if it's only a temporary solution, there's not much point.

[justinmk]

Are we going to stick with the status quo or bundle a client program for compatiblity with vim?

Neither. https://github.com/mhinz/neovim-remote is a temporary solution.

[lervag]

I'm curious: Is there any work on this yet? I am very much looking forward to neovim getting support for the --remote commands again!

[nadya-p]

neovim-remote plugin doesn't work on windows, so #8326 would be very helpful.

In particular, this would enable a neovim-based LaTeX workflow using vimtex and including its backward-search functionality (ability to jump from a line in pdf file back to the corresponding LaTeX source line in neovim).

[iamkarlson]

@nadya-p this would enable a lot of stuff. including but not limited to the case you sounded and also using neovim as git editor

[bfredl]

@iurobpn This is actively worked on in #8326

[iurobpn]

If anyone run into the same problem, this vimura script solved this for me. There are more steps in the link, but I just used the vimura to substitute my configuration of the zathura 'backward search'.

@yashamon , I used the nvr.