Small split-move related improvements #14185
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Problem: small improvements can be made to split-move related functions. Solution: apply them: - Improve some doc comments (frame_flatten should still work for non-current tabpages, despite the topframe check, which looks benign, though I'm unsure if it's still needed; see vim#2467). - f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's what win_splitmove checks (though it's probably unnecessary to check b_locked_split at all; see vim#14109, which I hope to get around to finishing at some point). - Make winframe_restore restore window positions for the altframe, which winframe_remove changes. This doesn't affect the prior behaviour, as we called win_comp_pos after, but as win_comp_pos only works for curtab, and winframe_remove supports non-current tabpages, we should undo it. Regardless, this should mean we don't need win_comp_pos anymore; adjust tests to check that window positions remain unchanged. I'm not sure win_comp_pos is needed after last_status anyway if it doesn't steal rows from another frame to make room for a new statusline, which shouldn't be the case after winframe_remove? To be safe, I'll leave it as is.
|
Thanks. |
seandewar
added a commit
to seandewar/neovim
that referenced
this pull request
Mar 12, 2024
Problem: small improvements can be made to split-move related
functions.
Solution: apply them (Sean Dewar):
Some of these changes were already applied to Nvim.
Here are the ones which were missing:
- Improve some doc comments (frame_flatten should still work for non-current
tabpages, despite the topframe check, which looks benign, though I'm unsure if
it's still needed; see vim/vim#2467).
- f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's
what win_splitmove checks (though it's probably unnecessary to check
b_locked_split at all; see vim/vim#14109, which I hope to get around to
finishing at some point).
- Apply the winframe_restore comment changes, and remove win_comp_pos from after
winframe_restore in win_splitmove, as it shouldn't be necessary (no need to
remove it from nvim_win_set_config too, as it was already omitted).
Move win_append after winframe_restore in win_splitmove to match Vim.
closes: vim/vim#14185
vim/vim@5cac1a9
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem: small improvements can be made to split-move related functions.
Solution: apply them:
Improve some doc comments (frame_flatten should still work for non-current tabpages, despite the topframe check, which looks benign, though I'm unsure if it's needed; see heap-use-after-free in win_equal_rec #2467).
f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's what win_splitmove checks (though it's probably unnecessary to check b_locked_split at all; see Relax split restrictions when split-moving windows #14109, which I hope to get around to finishing at some point).
Make winframe_restore restore window positions for the altframe, which winframe_remove changes. This doesn't affect the prior behaviour, as we called win_comp_pos after, but as win_comp_pos only works for curtab, and winframe_remove supports non-current tabpages, we should undo it. Regardless, this should mean we don't need win_comp_pos anymore; adjust tests to check that window positions remain unchanged.
To be honest, I'm not sure win_comp_pos is needed anyway after last_status if it's not stealing rows from another frame to make room for a new statusline, which shouldn't be the case after winframe_remove? To be safe, I'll leave that as is.