Neovide: Implement other GUI extensions

[smolck]

Currently Neovide implements ext_multigrid, but that's not the only GUI extension of Neovim; there's also ext_cmdline, ext_popumenu, ext_tabline, and others, which to my knowledge are not implemented. Implementing these would allow for more control over the display of the cmdline, pmenu, tabline, etc., and also could improve the look of things.

For instance, with ext_cmdline, the cmdline could be displayed more in the center of the screen, as it is in GNvim, GoNeovim, and others, which is arguably a nicer experience (don't have to look to the corner of the screen when opening/using the cmdline).

Considering the README says that Neovide should "functionally . . . act like the terminal UI," I'm not certain on the sentiment about these sorts of features, and so totally understand if this is not wanted, but figured I might as well open an issue on the topic.

[shaunsingh]

This is actually something we're interesting in working on soon. I'll close this issue in favor of these

https://github.com/Kethku/neovide/issues/233 (tabs and statusline), https://github.com/Kethku/neovide/issues/324 (command palette) and https://github.com/Kethku/neovide/issues/669 (minimap)

[Kethku]

I'm actually going to reopen this to encourage more conversation. @smolck something I've discussed here: https://github.com/Kethku/neovide/issues/669 is the idea of exposing graphics APIs to the vim side. Ideally these would be very simple vector graphics style drawing commands which take a window and potentially have a way to look up a grid location in pixel coordinates. Then implementing some forms of ui affordances is up to plugin authors.

To take this idea even further, if we enable font sizing on a window by window basis (not there yet, but within striking distance) we could even expose auto commands for drawing the command pallette/messages/popup menu. That way we'd get some of the benefit of those types of custom controls while still keeping things very vim centric. I don't have my heart set on this idea, but its got some appealing aspects because this sort of pattern could encourage other neovim guis to expose the same sort of thing and give more flexibility to plugin authors for crafting awesome experiences.

You mention the "functionally act like the terminal UI" comment in the readme. This was mostly a response to an issue I recognized with a couple of the existing neovim guis where it doesn't "feel" like neovim. Often they had ui components that I'm sure some people liked, but to me felt like add ons with minor improvements in terms of usability. Neovide isn't perfect in this regard (the cursor trails are purely silly) but when I consider new features to add to it, I'm looking for big usability gains. Some examples:

• the cursor animation allows users (and observers of people using the editor) to more easily track where the cursor has gone
• the window animations do the same thing when windows move around. Its much easier to understand how windows have changed if they subtly animate into position
• ditto scroll animations. Way easier to cycle through search results when the animation tells you vaguely where in the document you jumped to
• and lastly the blurred window background increases separation between the floating window and the main grid while still letting the upstream transparent window feature shine

My point is that these improvements are pretty targeted at an existing pain point. Adding infrastructure and maintenance burden ideally should come with a feature or friction improvement. Beyond that, I'm all ears!

[clason]

This is a bit of a "tag team" comment, so take it with a grain of salt, but:

1. I agree that exposing more configurability to neovim is good, but I'd do it in terms of Lua functions. (Not for the hype, but because Lua is more composable, and that's where neovim itself is moving for its newer API extensions.) This is an approach that uivonim was pushing rather heavily, see https://github.com/smolck/uivonim/tree/master/runtime/lua.
2. Continuing from that, I would focus less on low-level drawing primitives and more on high-level UI components which users can "opt-in" to slot in for native functions. As a primitive (hah!) example, neovim recently introduced a vim.notify() function that is slowly being used instead of pushing stuff to :messages. (Internally, it still does just that, but that makes it easy at some point for a user to just write lua vim.notify = neovide.notify to replace this globally with a native GUI notification center or whatnot). Longer-term, there's https://github.com/mjlbach/neovim-ui, which is pretty threadbare for now but will be a focus during the next development cycle or so. (So input from GUI devs is very useful now ;))

[Kethku]

@clason I've recently moved my vim config over to lua, and I agree it does appear to be strictly better and I really like that approach of using a lua function which can be dynamically overwritten. I hadn't thought about that, but that seems like a pretty slick way to go about it.

As for low-level drawing primitives vs high level components, I think my answer is to do both. Things like minimaps are really hard to implement without some form of low level drawing. Similarly, its really hard to render images in most neovim guis. So I would like to use both of those things as motivating use cases.

However I also find neovim-ui to be VERY interesting. I'm not sure how best I can help out with that effort as I don't actually write much in the way of neovim plugins (yet). I'll do some looking at the neovim-ui project in the coming days and get back to you

[clason]

Yes, one doesn't preclude the other. You can have a lower-level drawing API for plugins _and_ provide basic components built from them that a future neovim specification describes (notify, picker, etc. -- this is being discussed).

And I think the input from the "business end" side of things (GUIs that would implement their own version of these components, all shiny and chrome) would be just as valuable as input from "consumers" like plugins to map out the space of possibilities.