Closed vicrdguez closed 1 month ago
Hey, thanks for using the plugin and reporting the issue! ❤️
The behavior is a bit different when you enable NNP when there is already an split: sizes look fine, but as soon as you start adding more splits the issue appears again. Some "content buffers" end up as well with different size than others.
I'm not yet able to reproduce on nvim 0.9.5 and nnp 1.7.2, could you share the list of active plugins you have just in case it creates a conflict with NNP?
I have plenty, so I hope this does not clutter up the conversation too much. From Lazy:
● alpha-nvim 1.79ms VimEnter
● autolist.nvim 4.29ms markdown
● catppuccin 1.3ms catppuccin.groups.integrations.feline custom.feline
● cmp-buffer 0.28ms nvim-cmp
● cmp-nvim-lsp 0.32ms nvim-cmp
● cmp-nvim-lua 0.31ms nvim-cmp
● cmp-path 0.3ms nvim-cmp
● cmp_luasnip 0.27ms nvim-cmp
● conform.nvim 0.67ms start
● feline.nvim 0.05ms feline.providers.lsp catppuccin
● fzf-lua 4.76ms fzf-lua zk-nvim
● gitsigns.nvim 0.22ms start
● go.nvim 23.35ms CmdlineEnter
● guihua.lua 1.56ms go.nvim
● indent-blankline.nvim 2.01ms start
● lazy.nvim 10.13ms init.lua
● lsp-zero.nvim 0.92ms lsp-zero nvim-cmp
● lspkind.nvim 0.14ms nvim-cmp
● lua-async-await 0.54ms nvim-java
● LuaSnip 3.98ms nvim-cmp
● mason-lspconfig.nvim 0.71ms nvim-lspconfig
● mason.nvim 2.65ms start
● mini.ai 1.8ms start
● mini.comment 1.09ms start
● mini.cursorword 0.95ms start
● mini.hipatterns 1.7ms start
● mini.jump 1.84ms start
● mini.pairs 1.95ms start
● mini.splitjoin 0.99ms start
● mini.surround 1.52ms start
● no-neck-pain.nvim 3.08ms start
● noice.nvim 1.58ms VeryLazy
● nui.nvim 0.51ms nvim-java
● nvim-cmp 16.76ms start
● nvim-dap 0.65ms dap nvim-lspconfig
● nvim-java 62.91ms start
● nvim-java-core 0.48ms nvim-java
● nvim-java-dap 0.51ms nvim-java
● nvim-java-test 0.87ms nvim-java
● nvim-lspconfig 59.12ms nvim-java
● nvim-treesitter 8.06ms nvim-treesitter.parsers playground
● nvim-web-devicons 0.53ms trouble.nvim
● oil.nvim 3.17ms start
● peek.nvim 0.09ms BufRead
● playground 9.72ms start
● plenary.nvim 0.29ms start
● tokyonight.nvim 1.25ms start
● trouble.nvim 0.85ms start
● vim-fugitive 1.69ms start
● vim-rhubarb 0.39ms start
● zk-nvim 2ms <leader>rf
however I can't think on any that might be disturbing buffer resizing, but let me know if you notice any potential conflict!
Description
Hi!
first of all, thanks for the plugin!!
Here is the issue: Opening new splits has very inconsistent behavior with the plugin. Side panes seem to keep the same width regardless of the splits, which results in the actual buffers to just be smaller and smaller.
The behavior is a bit different when you enable NNP when there is already an split: sizes look fine, but as soon as you start adding more splits the issue appears again. Some "content buffers" end up as well with different size than others.
Easier to show than say, here is a recording of the issue:
https://github.com/shortcuts/no-neck-pain.nvim/assets/52254255/7a9c71b6-176a-4aed-90e6-e9cb5ad14808
Steps to reproduce
<C-w>v
Expected behavior
As you add splits NNP side panes should be made smaller, while "content panes" should keep taking over the screen while still being centered until side panes size is too small and they are closed.
At least that is the behavior I remember from using this plugin in the past
Environment