What happens currently if you try to use the smarter tabline with gnvim? I'm a bit skeptical if we need to add custom functionalities to gnvim for this.

@vhakulinen Forgive me, but I'm not certain I understand what you mean. I have the option to enable this (let g:airline#extensions#tabline#enabled = 1) set in my init.vim, but it is a vim-airline specific option. Currently, I just run gnvim with --disable-ext-tabline so that I can use vim-airline's smarter tabline. I don't think I can use it with GNvim currently?

I don't think I can use it with GNvim currently?

I have no idea, hence the question. I dont think it'll work.

Doing something gnvim specific to achieve the same effect feels a bit wrong because imo it should be something that nvim can provide through the UI API to all GUIs.

Doing something gnvim specific to achieve the same effect feels a bit wrong because imo it should be something that nvim can provide through the UI API to all GUIs.

Good point. Should an issue be submitted upstream to Neovim you think? I'm not sure; if this isn't possible with the normal neovim statusline, then they likely don't want to put some way of doing this into the API. That's assuming it isn't possible with the statusline though; I haven't scoured the docs, so I don't know if it is.

It might be worth it to go over to nvim's gitter and ask about this from the nvim devs.

As a sidenote I collaborated for a brief time on Oni and one of the things that I think degraded quality over time was the increasing surface area of custom features that were not able to be maintained (or improved).

I think this is a neat suggestion though and would likely try it out (although I don't have a buffer oriented workflow), just my two cents.

Perhaps we could create a tag or milestone for 1.0 focusing on bug bashing and must-have essential features to reach a stable core and consistent UI.

As a sidenote I collaborated for a brief time on Oni and one of the things that I think degraded quality over time was the increasing surface area of custom features that were not able to be maintained (or improved).

This is a good point. I think in order to make GNvim a worthwhile Neovim GUI, we need to keep in mind what makes (Neo)Vim great. I don't think our goal should be (and I don't think it currently is) to make an IDE, but instead to enhance the (Neo)Vim experience in a way that isn't possible with a terminal and in a way that stays true to Vim: all while keeping Neovim at the center of the editor.

For example, if we ever add a GUI file browser down the road, we would probably want to make it easily (and mainly) usable via custom (and user-configurable) keybindings that stay true to Vim (i.e. Ctrl-W-W to switch to it as usual, normal vim keys for navigation, etc.).

In terms of new features, I think we should think hard about whether or not each one should be in the core editor (GNvim itself). If we want something to shoot for for release 1.0+, how about making GNvim easily and seamlessly extensible via plugins/scripting? Thus, if users want a feature, they install a vim plugin (or something similar) like their used to (or make it themselves). What would be nice about this is that if a feature is wanted by people (but not in the core editor), they can maintain it themselves (through a plugin). In this way we learn from Oni's mistakes (and from Vim's amazing extensibility in spite of the lightweight core).

I think in order to make GNvim a worthwhile Neovim GUI, we need to keep in mind what makes (Neo)Vim great. I don't think our goal should be (and I don't think it currently is) to make an IDE, but instead to enhance the (Neo)Vim experience in a way that isn't possible with a terminal and in a way that stays true to Vim: all while keeping Neovim at the center of the editor.

Couldn't have said better 👏

If we want something to shoot for for release 1.0+, how about making GNvim easily and seamlessly extensible via plugins/scripting?

I was thinking of something less ambitious, first making sure we make GNvim good enough for massive daily usage with the current features we have (maybe stretching to leverage Neovim's 0.4.0 API, launching together).

Thus, if users want a feature, they install a vim plugin (or something similar) like their used to (or make it themselves). What would be nice about this is that if a feature is wanted by people (but not in the core editor), they can maintain it themselves (through a plugin). In this way we learn from Oni's mistakes (and from Vim's amazing extensibility in spite of the lightweight core).

Couldn't agree more, I think offering an API with such capabilities (via RPC with Lua/VimL or other way) would incentivize third-party plugins that could be elected for official support if/when a certain quality/usage threshold is met. That would certainly be one solution to feature creep.

As a sidenote I collaborated for a brief time on Oni and one of the things that I think degraded quality over time was the increasing surface area of custom features that were not able to be maintained (or improved).

This is certainly a valuable insight.

Gnvim was rewritten from ground up for gtk4. During this rewrite, I did experiment with this functionality (the buffers are now included in the tabline_update event). But since I don't personally use this feature (buffers in tabline), I didn't have the motivation to work on it.

With the rewrite done, this should be now pretty trivial to add. If someone wants to work on this, just give me a heads up so we can look a bit at the possible implementation. You can start from here: