-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
[Bug]: Offset only uses one window #789
Comments
Hi @FalcoGer, So this is an issue I've discussed many times over the course of the history of this feature leading all the way back to when I initially added it. It is absolutely not a full proof feature that covers all use cases perfectly. The main object was for it to be good enough for 90% of people's use cases e.g. having a file explorer open etc. The main difficulty with getting this perfectly right is that it works based on getting the window layout for nvim which comes in the form of nested array which describe the layout of neovim's windows. These array can be in a a lot of different configurations some of which apply to an offset and many more which don't. The offset logic just tries to find the ones that do apply and provide offsets for those. This may or may not be easily solvable by someone taking a look and having a go. When I implemented the feature I explained to the user who requested it at the time that it was going to be a good enough type solution not a perfect solution. I've also described this in many issues about this involving undotree et al. I'm a very big believer in community involvement in open source projects, I think if this bothers you you are very welcome to help contribute a fix and I can help guide that. This bug is not ideal but frankly the time it might take me to dig into this or how to fit this into the many many other issues and bugs across multiple plugins I have to deal with means this is not something I'm likely to personally prioritise as it doesn't affect me in my daily work at all. TLDR: PR welcome please 🙏🏾 otherwise I will leave this open for a week or two (or till I remember to check back) otherwise I will close this out. |
The problem is that I'm not very good at lua or vimscript. However it seems the problem appears to be solvable by examining |
@FalcoGer no vimscript knowledge is really required at all since there is not really any vimscript in this plugin and tbh lua is a very simple language. I think if you are able to configure your editor with it/know literally any programming languages that makes lua kind of trivial for this level of change. Thanks for digging into potential solutions. Seems this mechanism could maybe simplify things massively by just doing something like local offsets = {}
for _, win in ipairs(vim.fn.getwininfo()) do
if win.winrow == 2 and (wincol == 1 or wincol == max) then
table.insert(offsets, win.id)
end
end or something like this. You could just remove this logic and the usage bufferline.nvim/lua/bufferline/offset.lua Lines 108 to 121 in cd27a52
I think if you give it a try it'll be simpler than you thing probably and you can post questions here. |
It might not actually be winrow 2. probably best to get the minimum first. For example vim-airline has an option to be displayed at the top. not sure if it then goes above or below bufferline. Either way it will probably push the windows down into row 3. |
Hi @akinsho thanks for your work on this. I noticed the PR is still unmerged - is there anything blocking the merge? Maybe I can help? |
There are still bugs with that pr and I don't have time to work on it now |
Is there an existing issue for this?
What happened?
When multiple offsets are defined, then opening a new window will only apply the offset configuration to one window, usually the leftmost one or the last one opened. It behaves oddly.
For example when having an offset for filetype "help" and an offset for filetype "NvimTree", then opening NvimTree will produce the correct behavior. If you then however open the help with
:vertical help
, the help window gets the offset configuration applied but the nvim-tree gets it's text deleted.To reproduce:
Open nvim and only have one buffer open that doesn't have an offset setting for it's filetype
Open nvim-tree
Open vertical help
Notice help doesn't get the title and instead the bufferline starts over the help window
Close nvim-tree
Notice that help now gets the offset applied where before it did not
Windows that open on the right, such as tagbar, also behave oddly when opening and closing them mixed with opening and closing multiple windows that open on the left, such as undotree.
What did you expect to happen?
Vertically split windows always get their header text and all the offsets are added for the bufferline, except of course for the offsets for windows on the right, which should be handled separately
Config
Additional Information
N/A
commit
No response
The text was updated successfully, but these errors were encountered: