kevin/neovim
1
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2024-12-23 20:55:18 -07:00
Code Issues Packages Projects Releases Wiki Activity

remove "GUI architecture" section (moved to https://github.com/neovim/neovim/wiki/Plugin-UI-architecture )

Justin M. Keyes 2014-05-25 14:49:15 -07:00
parent 955d855fab
commit b82e7a61f3
1 changed files with 0 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
Introduction.md

@ -142,75 +142,6 @@ translated to json-rpc messages sent to vim.
[job control patch]: https://groups.google.com/forum/#!topic/vim_dev/QF7Bzh1YABU
[json-rpc]: http://www.jsonrpc.org/specification
<a name="gui"></a>
### New GUI architecture
Another contributing factor to vim's huge codebase is the explicit support for
dozens of widget toolkits for GUI interfaces. Like the legacy code support,
GUI-specific code will be removed.
Neovim will handle GUIs similarly to how it will handle plugins:
- GUIs are separate programs, possibly written in different programming languages.
- Neovim will use its own stdin/stdout to receive input and send updates, again
using json-rpc or msgpack-rpc.
The difference between plugins and GUIs is that plugins will be started by
neovim, whereas neovim will be started by programs running the GUI. Here's a
sample diagram of the process tree:
```
GUI program
|
`--> Neovim
|
`--> Plugin 1
|
`--> Plugin 2
|
`--> Plugin 3
```
Hypothetical GUI session:
```js
gui -> vim: {"id": 1, "method": "initClient", "params": {"size": {"rows": 20, "columns": 25}}}
vim -> gui: {"id": 1, "result": {"clientId": 1}}
vim -> gui: {"method": "redraw", "params": {"clientId": 1, "lines": {"5": " Welcome to neovim! "}}}
gui -> vim: {"id": 2, "method": "keyPress", "params": {"keys": ["H", "e", "l", "l", "o"]}}
vim -> gui: {"method": "redraw", "params": {"clientId": 1, "lines": {"1": "Hello ", "5": " "}}}
```
This new GUI architecture creates many interesting possibilities:
- Modern GUIs written in high-level programming languages that integrate better
with the operating system. We can have GUIs written using C#/WPF on Windows
or Ruby/Cocoa on OS X, for example.
- Plugins will be able to emit custom events that may be handled directly by
GUIs. This will enable the implementation of advanced features such as
Sublime's minimap.
- A multiplexing daemon could keep neovim instances running in a headless
server, while multiple remote GUIs could attach/detach to share editing
sessions.
- Simplified headless testing.
- Embedding the editor into other programs. In fact, a GUI can be seen as a
program that embeds neovim.
Here's a diagram that illustrates how a client-server process tree might look like:
```
Server daemon listening on tcp sockets <------ GUI 1 (attach/detach to running instances using tcp sockets)
| |
`--> Neovim |
| GUI 2 (sharing the same session with GUI 1)
`--> Plugin 1
|
`--> Plugin 2
|
`--> Plugin 3
```
<a name="development"></a>
### Development on GitHub