Fork me on GitHub
#vim
<
2016-12-09
>
jebberjeb16:12:49

@dominicm looking at https://github.com/neovim/node-host — trying to understand how to / if I should make neovim-client a “plugin host”?

jebberjeb16:12:47

Right, digesting this. So is the goal for the various plugin hosts to be distributed with Neovim? Or will they always require a separate install?

dominicm16:12:34

Always require a separate install.

dominicm16:12:51

Idea is to externalize this stuff. For example, if_python is now external.

jebberjeb16:12:27

I guess I’m trying to understand why that’s more desirable than distributing it as a library that plugins can just use.

dominicm16:12:48

@jebberjeb The idea is to remove some of the boilerplate required to make the RPC connection as a plugin.

dominicm16:12:51

https://neovim.io/doc/user/remote_plugin.html > Plugin hosts are programs that provide a high-level environment for plugins, taking care of most boilerplate involved in defining commands, autocmds, and functions that are implemented over |RPC| connections. Hosts are loaded only when one of their registered plugins require it, keeping Nvim's startup as fast as possible, even if many plugins/hosts are installed.

dominicm16:12:04

Screw you slack formatting -,-

snoe16:12:06

it sounds like neovim does want to solve automatically install a host if a plugin needs it

jebberjeb16:12:37

@dominicm hmm. I guess there is still some boilerplate w/ neovim-client. You have to “connect”. But after that, it removes any boilerplate associated w/ RPC. You just call functions.

dominicm16:12:22

neovim-client probably is an outlier really — it makes a lot more sense in python where you want to point them at an object or something.

dominicm16:12:52

Plus with macros in clojure, you can hide that boilerplate for me.

jebberjeb16:12:00

What should the name of neovim-client really be?

dominicm16:12:14

clojure(script?)-host

dominicm16:12:29

if you go down the plugin host route, anyway

jebberjeb16:12:46

how about if not?

dominicm16:12:57

Having said that, the python one is named python-client. So idk.

jebberjeb16:12:16

clojure-client.nvim maybe

dominicm16:12:36

Maybe python isn't the best one to look at

dominicm16:12:56

https://github.com/neovim/node-client I guess this is what neovim-client currently is?

dominicm16:12:38

A client that provides native functions for the neovim api it seems.

dominicm16:12:51

I imagine it's dynamically negotiated.

jebberjeb16:12:31

Yeah, looks similar. Yes, sets up the api wrapper functions dynamically.

jebberjeb16:12:39

neovim-client should do that I guess.

dominicm16:12:13

It would be super cool to have autocompletion for hacking on plugins 🙂

jebberjeb16:12:39

that would be useful yeah. I find myself invoking vim_get_api_info a lot now.

dominicm16:12:03

And software can automate that for you 😄 yay macros

jebberjeb17:12:10

hmm, looks like node-client generates their typescript declaration file and commits it. But still creates their api reflexively at runtime using vim_get_api_info. How does that not break plugins/consumers?

dominicm17:12:16

node-client probably isn't a great example of good code.

dominicm17:12:38

I also imagine that it's okay because the api won't deprecate from here (mostly)

jebberjeb17:12:48

I’ve noticed that even though Neovim api names changes, old names still work (despite their being missing from vim_get_api_info).

dominicm17:12:05

They're quite committed to a stable api

jebberjeb17:12:18

very Hickey-esque of them

dominicm17:12:20

Even though I know bugger all about the RPC api.

snoe17:12:56

the typescript declarations have been a source of breakage for me; I'm not a fan.

jebberjeb17:12:29

@snoe because they end up describing functions that don’t exist / are renamed?