I wonder if there should be some versioning of the nvim <-> host interface. Or perhaps nvim can ask the host for a list of capabilities (same as request names in most cases) rpcrequest(host, "capabilities") -> ["plugin_change_notify", "add_plugin", "try_reload_plugin", ...]

refs #5532 #4439 #4438

Or perhaps nvim can ask the host for a list of capabilities (same as request names in most cases)

More generally, some convention which identifies each channel (host, UI, or any other client) with at least a client name (like a user agent string) would be valuable. At least for error reporting, maybe also for UI configuration.

Yes, something like nvim_get_api_info, but in reverse.

The simplest thing might be to add a voluntary API function, e.g. nvim_set_channel_info. Then, even clients that aren't prepared to receive requests can still provide info.

We could also have a field in the nvim_ui_attach options that invites this info for UI clients.

That could work to implement this and be compatible with existing hosts. To still be able to get rid off "poll" #5856 and do it all async, we would need some kind of callback or autocommand, i e replace the poll command with

exe "autocmd OnChannelInfo "..host.channel.." call RegisterHostInfo("..host.name..")"

The feature also works for delayed loading plugins?

You mean not load all plugins in the host at once? The PR doesn't do it, but it is forward compatible with either nvim or the host doing it later.

You mean not load all plugins in the host at once?

Yes.

updated on top of #6743

Yes, something like nvim_get_api_info, but in reverse.

We can avoid that by simply requiring remote plugins to ship a lua/foo.lua file which defines commands/functions that call to the plugin's remote plugins. If that's too cumbersome, let's make it not cumbersome by enhancing the Lua stdlib once instead of adding tons of redundant code in every "remote plugin host". Then API clients can be much, much simpler.

• simplify remote plugins, massively #27949