Open Buffers/Files QuickOpen Window

[akinsho]

@bryphe now that oni has access to a list of buffers I was thinking that It would be really great to use this list as a quick open menu you could use to navigate different buffers.

In the same vein as fzf's :Buffers command which is what I currently use then you could use this menu to switch buffers. The difference between this and the regular find file command would be that it would only show you the files you have open rather than having to constantly filter through everything.

I realise that the file explorer will potentially solve this problem however my thinking was that generally I personally wouldn't open something like NERDtree or have a split in my editor to find my open buffers but would rather be shown a short list I could quickly select one from.

I can implement this (I think) but wanted to hear your thoughts before I went ahead in case you have other plans regarding something like this. My general thinking re implementation would be to add another function to the MenuManager like listOpenBuffers somehow getting that from the either redux or a vim event, probably redux

[bryphe]

@Akin909 - cool! I do find myself wanting this functionality from time-to-time. It always feels like too many keypresses to get at a buffer I just had open today 😄 I think there was some work / investigation here in #635 - so it might give you some ideas.

I can implement this (I think) but wanted to hear your thoughts before I went ahead in case you have other plans regarding something like this

Sounds good, thanks for sharing your ideas! I think it's fine to implement it stand-alone for now, but I'll give you an idea of what I'm thinking long-term too - eventually what I'd like is to have a 'modal' command-palette experience - similiar to how VSCode works. I like their system, as it's very discoverable to find functionality. If you haven't used it, they support 'prefixes'. Like if I have > as my first character, I'm in command mode, and all the results are commands. If I type ? as my character, I get info about what I can do with the command.

I'll create a separate issue that goes into more detail here - for this it'd be fine to implement separately for now as we think about how it could be combined.

My general thinking re implementation would be to add another function to the MenuManager like listOpenBuffers somehow getting that from the either redux or a vim event, probably redux

Ideally, we wouldn't need to extend MenuManager at all - it's pretty generic and really only cares about showing a menu. This would tightly couple it to the concept of a 'buffer', but it might not need that.

If you think of our current API as a set of building blocks, I think you could implement this with the 'building blocks' we have today:

Just some pseudocode:

const activate = (api: Oni.Plugin.Api) => {
    const menu = api.menu.create()

    menu.onItemSelected.subscribe((menuItem) => {
        api.editors.activeEditor.openFile(getFileFromMenuItem(menuItem))
    })

    menu.show()

    const buffers = getOpenFiles(api.editors)
    const buffersAsMenuitems = convertBuffersToMenuItems(buffers)
    menu.setItems(buffersAsMenuitems)

}

The cool thing about the Menu API is it's generic enough to support a lot of scenarios - we could do a colorscheme picker, list buffers, etc - it doesn't need to be coupled to a specific implementation. That way we can use it as a building block to support all kinds of scenarios 😄 It's basically connecting our 'Editor' and 'Menu' APIs to facilitate that scenario of listing the active files...

Ideally we'd have the above code hooked up to a 'command' and then a default key binding for it, too!

I realized that we don't have good typings for it right now:
https://github.com/onivim/oni-api/blob/8f59b3373cae9c013ab3cf701c850b4e3984aff3/src/index.ts#L243

Having that interface documented might make it more discoverable / understandable.

Hope those details are useful- let me know if you have any questions. Thanks for your help!

[akinsho]

@bryphe I'd still quite like to implement this but am stuck on how exactly as currently the Oni Api does not expose a list of buffers and I'm not sure how to get these through to the API, I wonder if you have any suggestions given the direction of Oni where would be best to put that method something like Oni.activeEditor.getCurrentBuffers and also how to pass the bufferlist which goes from the neovim editor straight to redux during the event handlers aka these are not available currently on request, I could potentially call the nvim function I created if I establish it as a vim command (apologies if this is waffly im potentially just rubber ducking here)

[bryphe]

Excellent! I'm really looking forward to this... lots of times when I'm working that I wish we had this functionality.

I wonder if you have any suggestions given the direction of Oni where would be best to put that method something like Oni.activeEditor.getCurrentBuffers

I think there are two options here -

Listen to onBufferEnter events

We could set up this UI to listen to the activeEditor's onBufferEnter events, and maintain its own set of buffer entries. This would require no changes to the API, but means that this provider would need to store its own set of data

Add a buffers API to the activeEditor

We could add a getBuffers(): Oni.Buffer[] property to the activeEditor, and use that. I think this is reasonable to add this extension to the API, and it would help support this use case plus some otherwise. (Pretty much the same as your suggestion, just thinking getBuffers might be simpler than getCurrentBuffers, because it might be confusing to rationalize what 'current' and 'active' mean with regards to our existing activeBuffer API).

and also how to pass the bufferlist which goes from the neovim editor straight to redux during the event handlers aka these are not available currently on request, I could potentially call the nvim function I created if I establish it as a vim command (apologies if this is waffly im potentially just rubber ducking here)

We should have most of the info available already - there is the BufferManager class that keeps around the list of Oni.Buffers that the editor knows about (And NeovimEditor has an instance of it via this._bufferManager). We'd just need to plumb the data through for our new API method.

I think the second approach is reasonable, would be a useful API to have in general. Once we have that API on the editor object, we could grab the active buffers, and create a menu with MenuManager, and populate it with data from our new API call.

Hope that helps, lmk if you have questions!