docs: --remote alternatives

[justinmk]

WIP: sketching out how Nvim --remote should work.

Key ideas:

• The numerous --remote-x-y variants from Vim should not be mindlessly copied. Most use of --remote is for small one-liner shortcuts. Any non-trivial use of Vim's --remote is not going to work with Nvim because we don't and won't have exactly the same interface. So we can instead just make a better interface.
• If possible, the only --remote variant we will support is... --remote. Not the other stuff.
• The usual Nvim CLI options like -p, -es, etc., should "just work". For example,
  • -p --remote should work, then --remote-tab isn't needed.
  • -es "+echo 1+1" --remote should work, then --remote-expr isn't needed.
  • echo <keys> | nvim -s - --remote should work, then --remote-send isn't needed.
    • Alternatively "+call nvim_input('<keys>')"

Another note about the current behavior:

This doesn't work, all arguments after --remote will be used as file names: >
    nvim --remote --server ~/.cache/nvim/server.pipe file.txt

What is the purpose of that? We already have -- (:help ---) for declaring "all args hereafter are filenames".

close #18531
close #18519

[Shougo]

Hi. I have checked the PR. --remote-wait seems not implemented. I think it is needed to ues neovim as git $EDITOR.

[groves]

Here's my immediate reactions on reading this:

• Is there any point to having a --remote flag now? With this, it feels like --server says do what you would normally do with these command line args but in the given server. That makes --remote feel redundant since you have to specify an address. Dropping the remote flag altogether has the benefit of making it clearer that this isn't flag-for-flag compatible with vim
• I agree with @Shougo that wait feature is quite useful. If you look at the wait code in the existing PR, it's definitely the most obnoxious bit to implement. I'm also not super happy with how it's tied to waiting for BufUnload. That matches the Vim behavior, but it's not as clear a choice for an event as NeoVim has hidden on by default. It seems like we should either use a separate event or allow the user to easily specify what condition they'd like to wait on or something like that. No good mechanism is jumping out at me though.
• The way the Vim implementation allows you to become the server if there isn't something listening on that address has been helpful for me in the past. I don't like how it does that by default though, makes it easy for stuff to break silently. Maybe we could add a --listen-if-no-server flag to allow that? Should probably figure out a better name though 😂
• The current NeoVim remote implementation doesn't load plugins or user config to let it get to issuing RPC calls with as little overhead as possible. I think that should be fine with this proposal since we're not really running user code in the client and I don't think users would expect to have their plugins loaded as a result. Wanted to call it out in case there's something I'm missing though.
• I imagine we'd want to come up with a list of flags that are disallowed like -i, -m, -n, -r, -R. Would want to have the client exit if they're specified in combination with --server so the user isn't confused when they do nothing.
• Maybe there's another smaller set that we document as affecting the client, not the server? -V, --startuptime, -v
• Should -u <config> get the server to load a config file? There's so many command line options that could conceivably be sent to the server: -o, -O, -t, -q, +[num], +/{pat}, -S {file}, etc. Maybe we want to add those to a not-currently-implemented list that bails on startup and let people add them as they find the need? Feels daunting to try to get all of them at once.

[groves]

This doesn't work, all arguments after --remote will be used as file names: >
    nvim --remote --server ~/.cache/nvim/server.pipe file.txt

What is the purpose of that?

It was in the original PR I based my PR on and it matches the Vim behavior. I'm not positive of the purpose, but my guess is that it's just there to make the implementation simpler. That could likely be cleaned up if local and server command line parsing were unified as part of this proposal.

[justinmk]

• Maybe we want to add those to a not-currently-implemented list that bails on startup and let people add them as they find the need? Feels daunting to try to get all of them at once.

Yes. We can document what's currently supported and reject everything else, then improve incrementally.