[Feature request] relative buffer numbers

[rod-stuchi]

What happened?

All good up to here

But, if I hit <Leader7> it stays at file006 ordinal 6

if I hit <Leader1> it goes to file004, with ordinal 4

What did you expect to happen?

Should this ordinals be dynamic?

Additional Information

...

commit

No response

[akinsho]

@rod-stuchi no they aren't static, they represent the visible position of the buffer in the bar so as you move through visible buffers and the list shifts the numbers will shift

[rod-stuchi]

Thanks @akinsho So in this case, it could be a bug in mappings? In the flow up above, if I hit <Leader>1 it goes to file004 (ordinal 4), but the correct was to select file001 (ordinal 1).

IMO, I think it is cooler to select ordinal according to what is visible, if file001 was offset, file004 should be (ordinal 1) but the ordinal number should be updated visually, but the ordinal number get updated only by moving its position. I don't know if this is even possible.

[rod-stuchi]

Hi @akinsho , this video (with screenkey) shows better what happen.

https://user-images.githubusercontent.com/19471811/140372078-e69d13fe-10f8-462f-9072-8a16d4b1343b.mp4

My mappings, Leader = ','

keymap('n', '<Leader>1', '<Cmd>BufferLineGoToBuffer 1<CR>', opts)
keymap('n', '<Leader>2', '<Cmd>BufferLineGoToBuffer 2<CR>', opts)
keymap('n', '<Leader>3', '<Cmd>BufferLineGoToBuffer 3<CR>', opts)
keymap('n', '<Leader>4', '<Cmd>BufferLineGoToBuffer 4<CR>', opts)
keymap('n', '<Leader>5', '<Cmd>BufferLineGoToBuffer 5<CR>', opts)
keymap('n', '<Leader>6', '<Cmd>BufferLineGoToBuffer 6<CR>', opts)
keymap('n', '<Leader>7', '<Cmd>BufferLineGoToBuffer 7<CR>', opts)
keymap('n', '<Leader>8', '<Cmd>BufferLineGoToBuffer 8<CR>', opts)
keymap('n', '<Leader>9', '<Cmd>BufferLineGoToBuffer 9<CR>', opts)

Numbers format

numbers = function(opts)
  return string.format('%s|%s', opts.id, opts.raise(opts.ordinal))
end,

The behavior is Ok, meaning the buffer ordinal 1 is what I'm seeing, if a hit ,1 it goes there, but the ordinal indicator is showing a static number (e.g: 4, assigned when file was open), if the ordinal numbers don't update when some buffer are offset, I have to memorize which position, I mean, e.g. if shows ordinal 4 but in fact it's ordinal 1

[akinsho]

@rod-stuchi thanks for the video and clarification, the whole bufferline should be redrawn when you enter a new buffer, so the ordinal numbers should change. Tbh the whole number feature is something I don't use at all that I added because of user requests and have tweaked further because of subsequent requests. Since I don't use it, I rarely see bugs with it.

I don't have much time to dig into this at the moment, happy to guide a PR though if you're willing, if not will leave this open for some future point or potential future contributor.

[rod-stuchi]

Hi @akinsho

Thank you for the guidance offer!

I'll take my chances trying to fix this issue, that will help my workflow a lot

[akinsho]

@rod-stuchi so it turns out I was incorrect when I described this as a bug, it's actually been raised a few times and most recently in #251, so I'll close one of these 2 issues as a duplicate. It isn't a bug that the ordinal number is "static" since that is an absolute count of the buffers in the total list. This is actually not a bug, but a feature request to show the visible count as well. This is a little complicated because we only know the visible position after we have already tried to draw the buffers, so they'd have to be redrawn again, which will have a performance penalty (probably minor given how fast lua is 🤷🏿‍♂️ ).

Tbh, I think the numbers feature personally is becoming more effort to maintain than it's worth, but there is enough demand so fine to merge a solution, but it would have to gate this extra redraw of visible buffers to only people using the numbers feature.

I'll sketch out a potential guide to the solution later on today.

[sandangel]

Thanks @akinsho for your flexibility. Im also willing to help. BTW it's still a great plugin even without this feature and I really appreciate your effort to create and share with us. ❤️❤️

[sandangel]

btw I think we dont need an exact visible order on bufferline. for example the first visible one could be 2 instead of 1. With that in mind I think we can try an approach that pre calculate the visible number based on the number of buffers, screen width. When we select 1 buffer, we just need to populate the precalculated visible number if this buffer is selected.

[rod-stuchi]

for example the first visible one could be 2 instead of 1

That's a great idea, this way we could navigate to not visible buffers to the left with 1, and some X visible buffer + 1 to the right.

[yutkat]

Maybe this map can do it?

vim.keymap.set("n", "<Leader>1", function()
    require("bufferline").go_to_buffer(1, true)
end, { noremap = true, silent = true })