-
-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Reexposing groups and statuses like is_pinned
.
#736
Comments
Hi @cenk1cenk2, That's a really unfortunate feature/behaviour of lua that I can't hide private implementation details. I would have/strongly advise against using the internal APIs like this. Unfortunately it ties my hands way too much to have to worry about breaking users configs if they are using things I haven't explicitly exposed. I think as a general rule to maintain my sanity if a module isn't documented as exposed it should be treated as private and I will tweak those things as needed. So I don't want to revert this since one of the reasons I changed this was because I didn't want these things exposed by accident so people wouldn't use them. Going forward I will actively actually try to hide anything that I can since I really don't want the internals of this plugin exposed by accident. That being said I'm open to providing public APIs for achieving some common/valuable features. Maybe you can list out what functionality you are trying to achieve then I can think of if it's easy/possible etc. It's important not to focus on the internal API but on the functionality you want since ultimately a lot of the internals can and will change over time definitely. |
Hey @akinsho, Thank you for your time and detailed answer. I do 100% agree on keeping private things private as you said and fully support the changes. In my case, I do only need to know if a certain buffer with a number is in a certain group. I suppose that can be a useful feature if anybody has implemented a functionality like me closing everything unless they are pinned. I suppose this has been discussed many times before like #580, #309, therefore, might be worthy of the public API. |
@cenk1cenk2 there is already a command called The reason I closed those other issues is that users have been trying to nudge this plugin into doing buffer management but I've explained many times that the object of this plugin is UI it's not a tool designed for buffer management |
I guess you could add to group close with an |
To be honest, the only thing that can solve my use case is to have a function that can check whether the buffer is certain group. I have missed the commands like But with that said I sincerly thank you for taking your time and very grateful for all the answers as well as if you do not see it fit to have this on the public API, I still totaly understand that since it can be a very specific use-case that does not comply with having a clean way to manage buffers. |
So I think I still misunderstand the use case because it sounds like you just want to be able to close all buffer not inside of a group e.g. close all unpinned buffers. This should be easy enough by changing the It seems like this would solve your issue? why do you think you'd still need a function to manually check the groups? |
Sorry for a bit beating around the bush and wasting your time without a proper use case. The addition of So for an example use-case of the one that has been mentioned in the prior issues which are "close all buffers but current", where it can be supported with my hacky version of the code found here.
OFC, this can be got around by pinning the actual buffer first then, closing all except pinned, then unpinning the buffer with current structure. Another use case that I can throw in the mix is something like "smart quit", where it would prompt
Thank you again for your time on this issue and sorry for not being as straightforward with the use case. |
Hey, just hopping in I was actually working on a similar thing, problem is that i navigate code and start opening multiple buffers and it gets out of control, so I was thinking about how to close my buffers in a keystroke I was thinking to propose a "close_by" API call which will just provide a filter function ( similar to the sort_by ) and then close if true or false, this would allow extensibility to anyone who needs it, but i'm afraid it will be rejected for falling on the "buffer management" realm problem i've found is that my UI doesn't refresh if I close the buffer manually also, a sugestion, instead of using is_pinned you can check the group name, my approach to an external close_by looks like this: local function buffers_close_by(func)
local elements = bufferline.get_elements().elements
for index in ipairs(elements) do
bufferline.exec(index, function(buf)
if func(buf) then
close_buffer(buf)
end
end)
end
end
|
Yeah I now realize that I use the archaic version of the API to try to achieve what I am doing. Thanks for the heads up @kasthor. |
So a lot of these use cases fall into the buffer management plugin space which I often find there are already enough solutions for in other plugins or natively. Some examples of good plugins that solve buffer management well already are:
For example close all but current gets mentioned a lot but neovim already has a pretty simple solution for a basic version of this which is
The complex combination of close all that aren't pinned except the current one I think is outside the realm of general enough to add to the plugin this seems like something quite specific to a workflow and not generally applicable. In general to clarify the only buffer "management" commands in this plugin only exist because they operate through or on something that only this plugin is aware of/created e.g. groups, this is the requirement for it being added to this plugin, it solves a problem that only this plugin can solve (which is often because it's a paradigm created by this plugin). Anyway the TLDR is, some sort of |
@kasthor your snippet/desired functionality can be achieved entirely without bufferline existing or being involved e.g. for _, id in ipairs(vim.api.nvim_list_bufs()) do
if vim.api.nvim_buf_is_valid(id) then
-- you can do whatever you want based on
-- vim.bo
local modified = vim.bo[id].modified
local buftype = vim.bo[id].buftype
local filetype = vim.bo[id].filetype
local name = vim.api.nvim_buf_get_name(id)
if predicate_i_want then
vim.api.nvim_buf_delete(id, { force = true})
end
end
end
|
With the future addition of the I am also one of the people who would really like to be able to do this, I often want to close all my tabs except the one I'm currently editing, and without losing all the important pinned ones. |
@Gremious function()
local bufferline = require("bufferline")
local commands = require("bufferline.commands")
local current = vim.api.nvim_get_current_buf()
vim.schedule(function()
for _, e in ipairs(bufferline.get_elements().elements) do
local is_current = e.id == current
local is_pinned = bufferline.groups._is_pinned(e)
if not is_current and not is_pinned then
commands.unpin_and_close(e.id)
end
end
end)
end |
Thank you for your time on this, I would just close this to reduce clutter. |
What?
Hello @akinsho,
Thank you for maintaining this plugin for such a long time.
With the latest changes,
"bufferline.groups"
no longer expose the groups for manipulation/look-up except for testing. If it is not much of a hassle can these be reexported?I might be missing the other way to implement this but thank you so much for your time either way.
Why?
I know this is the internal API of the plugin but I have been heavily using it to implement functionality like closing all buffers but current except for the pinned ones, maybe that would be the case for others too.
These use cases like closing all but current were discussed in an issue before and you have indicated that this is easily implementable. Still, with the API no longer exposing them, it is impossible to do so anymore.
The text was updated successfully, but these errors were encountered: