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?
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.
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.
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).
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'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.
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.
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?