[Feature Request]: Be able to cycle through buffers with `BufferLineCycleNext` even when `showtabline = 0`

[pocco81]

What?

I'd like to be able to cycle to the next/prev buffer by using BufferLineCycleNext/Prev while showtabline = 0 so that I can get a minimal-feel while loosing none of buffer switching functionality. The see the current behavior:

1. Open a file
2. Set set showtabline=0
3. Open another file (e.g. e hello.txt)
4. Try to cycle through the buffers using BufferLineCycle*. Doesn't work, whereas if you try bnext and bprevious they both work.

Why?

I wanted to add an integration for bufferline into one of my plugins. My plugin has different modes, one being minimalist mode, which hides stuff such as the tabline, statusline, numbers, signcolumn, ... The problem is that if I go into minimalist mode (thereby setting showtabline = 0), open a new file and try to switch between buffers using Bufferline.nvim's commands while on the new file I opened, they don't work, however both bnext and bprevious do.

Alternatively it would be nice to have an api to sort of "register the newly created buffer to Bufferline's buffer list" so that it be cycled through. Granted, perhaps this is already possible? in that case I would like to be pointed to the right method/func.

Thanks :)

[akinsho]

Hi @Pocco81,

so I think the reason this doesn't work is quite a tough problem to solve, essentially when you set showtabline=0 manually it means that bufferline isn't running basically every redraw the bufferline function is called and populates the buffer state and does the drawing. When showtabline is 0 that function which is the entry point to this plugin isn't being called at all. So there are no buffers in state and the plugin is almost essentially disabled. The commands are created regardless, though.

Trying to make the bufferline run in the same way despite the main bufferline function being called will be a big pain in the butt I think, and tbh I think of it as a performance advantage that whilst showtabline is 0 the plugin doesn't do unnecessary work.

The best solution I see here is that if showtabline is 0 then those commands can instead just run bnext and bprev whereas normally they look at bufferline state based on the visible buffer layout and decide where to go, but as I've said there is no internal state since nothing is visible when showtabline is 0

[pocco81]

The best solution I see here is that if showtabline is 0 then those commands can instead just run bnext and bprev whereas normally they look at bufferline state based on the visible buffer layout and decide where to go, but as I've said there is no internal state since nothing is visible when showtabline is 0

That's a pretty good solution. It would be lovely if you were to add this feature!

Regardless, to my understanding: if you change the order of buffers :bnext and :bprevious will not respect the custom ordering. So since you said that, in our case, setting showtabline = 0 disables bufferline, I assume that it's inevitable for this to mess up with bufferlines' Cycle commands.

Is there any workaround that could be done on my end? Perhaps there is an API to add the current buffer to Bufferlines' buffer array?

[akinsho]

I think the solution if you want to maintain custom cycling via bufferline then really bufferline has to be running since otherwise that's sort of a chicken and egg problem.

I don't think there's another solution that won't introduce a performance penalty of having things run constantly, even when not visible to every other user in all other scenarios.

Re. the bufferline buffer state and altering it, bufferline gets its buffers from neovim on every redraw, it simply replicates neovim's internal state so if vim sees it bufferline will see it.

If a person is hiding the tabline then to my mind they won't be expecting for it to cycle according to bufferline's ordering because they can't even see bufferline to know what order it has.

Technically you could add a buffer to bufferlines state object manually as long as it conformed to bufferline's buffer class, but tbh a lot of this to be frank is quite convoluted/invasive since it kind of goes against how I implemented bufferline. The idea with it and all of its commands is that it would be running and visible.

I think just doing bnext/bprev is a good compromise, but if a person is trying to do a bunch of navigation via bufferline without seeing bufferline then this is a weird edge case to accommodate.

[pocco81]

Understandable. Let's keep it simple then :)

[akinsho]

Gonna close this out as I've merged the change into my dev branch. It will make it's way to main when I do the next release soon.