Skip to content

fix: properly compute remaining width after integrations#469

Merged
shortcuts merged 11 commits intomainfrom
fix/width-compute-integrations
May 29, 2025
Merged

fix: properly compute remaining width after integrations#469
shortcuts merged 11 commits intomainfrom
fix/width-compute-integrations

Conversation

@shortcuts
Copy link
Copy Markdown
Owner

@shortcuts shortcuts commented May 19, 2025

📃 Summary

closes #453
closes #470

the width of an integration doesn't need to be accounted as a vsplit occupied width, but should rather just be deduced from the remaining width for the side buffers

@bew
Copy link
Copy Markdown

bew commented May 20, 2025

I tried this branch but didn't see much improvement unfortunately 👀
Ping me when you want and I can test the change (or test it yourself, as you like ¯\_(ツ)_/¯)

@shortcuts
Copy link
Copy Markdown
Owner Author

I tried this branch but didn't see much improvement unfortunately 👀 Ping me when you want and I can test the change (or test it yourself, as you like ¯\_(ツ)_/¯)

ah yes it's not ready yet sorry for the false alarm

@shortcuts shortcuts marked this pull request as ready for review May 29, 2025 22:36
@shortcuts shortcuts merged commit 4367884 into main May 29, 2025
7 checks passed
@shortcuts shortcuts deleted the fix/width-compute-integrations branch May 29, 2025 22:38
shortcuts pushed a commit that referenced this pull request May 29, 2025
🤖 I have created a release *beep* *boop*
---


##
[2.4.3](v2.4.2...v2.4.3)
(2025-05-29)


### Bug Fixes

* properly compute remaining width after integrations
([#469](#469))
([4367884](4367884))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@ezequiel
Copy link
Copy Markdown

@shortcuts Thanks for the great work here. Noticed a new issue after this commit-- there's now a severe delay before the resizing kicks in, where as before it was near instant

Before After
before after

Config:
https://github.com/ezequiel/dotfiles/blob/main/dot_config/nvim/lua/plugins/no-neck-pain.lua

@shortcuts
Copy link
Copy Markdown
Owner Author

@shortcuts Thanks for the great work here. Noticed a new issue after this commit-- there's now a severe delay before the resizing kicks in, where as before it was near instant

|Before|After|

|------|-----|

|before|after|

Config:

https://github.com/ezequiel/dotfiles/blob/main/dot_config/nvim/lua/plugins/no-neck-pain.lua

Oh wow thanks for testing and reporting the issue! Has the video been slowed down for demonstration purpose? There is indeed an added debounce of 2ms which I wasn't expecting to be so noticeable

I think I might have a workaround to only debounce when a sidebar is active 🤔 I'll try that asap

@ezequiel
Copy link
Copy Markdown

ezequiel commented May 31, 2025

Sounds good! Happy to test once available -- and no, no artificial delay or slow down introduced 😅 My config is slightly unique, so it may have added some randomness to the mix

@shortcuts
Copy link
Copy Markdown
Owner Author

Sounds good! Happy to test once available -- and no, no artificial delay or slow down introduced 😅 My config is slightly unique, so it may have added some randomness to the mix

Could you please let me know if using the built-in option to enable on vim enter (https://github.com/ezequiel/dotfiles/blob/main/dot_config/nvim/lua/plugins/no-neck-pain.lua#L8 set this to true, or "safe" if you want dashboard support)

I'm not able to reproduce and all I can think of is that you use the VimEnter event, which is executed later than BufEnter

shortcuts added a commit that referenced this pull request Jun 2, 2025
## 📃 Summary

so it turns out that it's the resizing of the "every other windows" (non
side windows) that causes the problem of the weird layout described in
#472,
#453,
#469 and
#470

after a side window has been resized, the other vsplits (except
integrations) gets resized as well, which shifts the layout when only on
side is enabled, but not when there's two.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug]: interaction with nvim-dap-ui causes windows size problems [bug]: NvimTree buffer too wide when reopening after starting NoNeckPain

3 participants