Neovim Plugin UI architecture | Hacker News Reader

Neovim Plugin UI architecture

github.com

133 pointstambourine_man13 comments

Question from the uninitiated: in the 'old days', you'd write or expose a C library. Most languages support C APIs without too much work and you don't need to serialize/deserialize data structures.

Although the described approach has some advantages (a plugin is separate from the Neovim process, can run across a network, etc.), I wonder if in some situations this doesn't give to much overhead. E.g. if someone is scrolling fast, do you really want to communicate with all plugins over a named pipe or socket, doing messagepack serialization/deserialization?

Good point, but I assume a plugin only receives events it subsribed for, so it's not that for any event all plugins have to be notified. Also consider that the combination of serialization/local pipe/deserialisation may sound like something huge, but in reality probably only takes a couple of mSec. On the other hand: if it really goes over TCP/IP on another machine on another network, the lag should be noticable. But I doubt there are many plugins like that.

On a sidenote: C apis are still used widely. And there are enough libraries out there to put an extra IPC layer on top of it so the'll behave the same as this one (i.e. can communicate though pipe/socket/... of choice).

Vi was designed to work over a 300 baud modem. The throughput needed for a text editor is minimal (and still is). A C API would avoid the extra overhead, but no one is interested in writing cross platform unicode/binary safe plugins in the language. Also consider that buggy plugins that live in other processes won't crash the editor.

By the way: 300 bps, not 300 baud. Baud is something different and you can transfer a lot more bits per second with 300 baud than just 300.

No, 300 baud. This comes from a direct quote by Bill Joy[0]:

"No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem."

[0] http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...

Although you're technically correct (since baud connotes the rate of change of the signal and not the rate of data communicated over that signal), modems didn't start sending more than one bit per baud until we got to higher data rates. At the time vi was written, 300 baud was in fact equivalent to 300 bps and the terms were used interchangeably.

MacVim uses the same model: Every MacVim window talks to one vim process behind the scenes. It seems to work very well in practice.

I have never profiled where the bottleneck is, but if I had relativenumber and cursorline set, I could see it literally redraw the screen (on both Intel and nVidia GPUs). Luckily, it's a bit better now on my MacBook Air 2012 and the latest MacVim. But it used to be so bad that I often unset these options.

I hope this works out well for Windows users who run 20+ plugins -- no zombies or anything when neovim crashes.

I'm thinking that it won't be necessary to split out all plugins into separate processes. One could just as well use one host per scripting language and combine all plugins that use the same scripting language.

Exactly, only the host process needs to implement the event loop described in the wiki.

The host can also implement custom discovery/loading of plugins in a way that makes usage of the subscribe/unsubscribe API completely transparent

Still, IMHO, nice to split them out -- so they don't stomp on each other or do other silly things. Same reason it is nice (but not memory efficient) that Chrome does this... individual processes are safe and sane.

Neovim looks promising. Not to derail the thread but is there a similar reimplementation effort on the Emacs side?

Reply on news.ycombinator.com