bufferline.nvim
bufferline.nvim copied to clipboard
[Feature request] make the numbers always ordered as they appear from left to right
As you see the numbers are out of order 1, 2, 4, 3, however I want the numbers to correspond to the order which they appear, so 1, 2, 3, 4.
Here is my configuration:
require('bufferline').setup {
options = {
numbers = function(opts)
return string.format('%s', opts.ordinal)
end,
offsets = {{filetype = "NvimTree", text = "File Explorer", text_align = "center"}},
separator_style = "slant",
groups = {
options = {
toggle_hidden_on_enter = true -- when you re-enter a hidden group this options re-opens that group so the buffer is visible
},
items = {
{
name = "Tests", -- Mandatory
priority = 2, -- determines where it will appear relative to other groups (Optional)
matcher = function(buf) -- Mandatory%
return buf.filename:match('test_.*') or buf.filename:match('%_test')
end,
},
{
name = "Src",
priority=1,
matcher = function(buf)
return buf.filename:match('%.py')
end,
},
{
name = "Misc",
priority=3,
matcher = function(buf)
return buf.filename:match('.*')
end,
},
}
}
-- diagnostics = "nvim_lsp",
-- diagnostics_indicator = function(count, level, diagnostics_dict, context)
-- local s = " "
-- for e, n in pairs(diagnostics_dict) do
-- local sym = e == "error" and " "
-- or (e == "warning" and " " or "" )
-- s = s .. n .. sym
-- end
-- return s
-- end,p
},
}
This is likely an issue specifically to do with mixing grouping and numbers, tbh I don't use numbers and very often consider deprecating them since it's something I don't use which I added due to previous feature requests that just creates never ending work, unfortunately. I didn't test them with the grouping functionality and tbh they are unlikely to be compatible, definitely for the time being as the grouping functionality is experimental.
If you are willing to dig in, I can help guide a PR to fix it maybe, or you can disable one or the other option. As I mentioned in the other issue, I have to focus on other pieces of work right now and can't get stuck into any of these issues myself at the moment.
👋 I have a similar issue with - I think- a simpler configuration:
and my config is
require("bufferline").setup({
options = {
mode = "tabs",
numbers = function(opts)
return string.format('%s·', opts.raise(opts.ordinal))
end,
diagnostics = "nvim_lsp",
offsets = {
{
filetype = "NvimTree",
text = "Directory:",
highlight = "Directory",
text_align = "left"
}
},
separator_style = "slant"
}
})
I notice it most when I gt
and gT
to cycle through tabs and they don't cycle in my expected order (left to right with gt
).
I'd be happy to attempt a PR for this :)
@felipesere gt
and gT
are not by default aware of the order in which bufferline has sorted the tabline. It's recommended to use CycleNext/Prev
instead to see more consistent results.
Regarding this issue, tbh I don't/can't really devote much time to number related functionality, anyone wanting to do any tweaks should have a read through the code and sketch out an idea for a solution here, and then I can take a look if they raise a PR.
Frankly the numbers feature is kind of expensive in the amount of time I spend hearing about its issues and I think generally I'm beginning to lean towards just deprecating it entirely to reduce complexity and issues relating to it.
This is a really useful feature to me. Bufferline is the best tabline I've yet to use so don't break my heart @akinsho and rip it out haha! I hear you on the busy part and needing to focus elsewhere.
When I get some free time I'll take a look at this situation myself and hopefully open a PR.
Tab sorting is fixed in https://github.com/akinsho/bufferline.nvim/pull/592. This makes it aware of gt
and gT
by default.
fixed by #592