Also, if I am not mistaken, the code that handles the multiplexing (multigrid) was not made only for this feature, but a generalization that improves a lot of capabilities for GUIs.
This is reasonable enough, but personally I'm not really convinced a text editor should be handling windows at all, especially since neovim allegedly is designed to be embedded by a ‘real’ UI (and presumably could be embedded by a terminal-based UI that handles windows—or just uses tmux).
I do recognize that I prefer software to be simpler than most people (for the record, much of the time I use ed(1)).
That's an extremely cool party trick but I'm also slightly concerned that neovim started to cut bloat in vim and ended up implementing a compositing window manager with fake transparency.
Though the idea is just pretty damn cool in general so I can't get too grumpy about it.
On the bright side, this is actually a demonstration of the extensive work the neovim team has done cleaning up the UI layers. justinmk's comment above goes into more detail, but basically vim has gone from having a single array of characters that gets manipulated by every type of display item to windows with their own positioning and dimensions. In addition, these windows will be exposed via APIs that external GUIs can use.
> slightly concerned that neovim started to cut bloat in vim and ended up implementing a compositing window manager with fake transparency.
"Window manager" existed since vim got split-windows (1990s). Redesigning it as a compositor:
- isolates windows logically, so that UIs can do their own layout instead of being stuck with the TUI grid
- useful for implementing floating windows
- allows reasoning about layers instead of one grid driven by special-cases throughout the project
- helps with features such as "click through", z-index, etc.
The blending (fake transparency) was a small (~200 LoC) amount of code, added only for fun (and to ruffle feathers).