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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relax split restrictions when split-moving windows #14109
Draft
seandewar
wants to merge
1
commit into
vim:master
Choose a base branch
from
seandewar:splitmove-locky
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
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: split-moving is disallowed on windows with closing buffers. This seems necessary, as unlike regular splitting, no new views into a buffer are created. Solution: relax the restriction, test that removing the restriction is fine for split-moves (ensure it crashes when the b_locked_split check for regular splitting is deleted). Also fix l:close_win in Test_win_splitmove to be a window ID instead, as expected.
Yeah the patch I made only addresses BufLeave autocommands, however the same can probably happen for other autocommands. We should try to make this more central. Thanks |
seandewar
added a commit
to seandewar/vim
that referenced
this pull request
Mar 12, 2024
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). - 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. 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.
seandewar
added a commit
to seandewar/vim
that referenced
this pull request
Mar 12, 2024
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.
chrisbra
pushed a commit
that referenced
this pull request
Mar 12, 2024
Problem: small improvements can be made to split-move related functions. Solution: apply them (Sean Dewar): - 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 #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 #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. closes: #14185 Signed-off-by: Sean Dewar <[email protected]> Signed-off-by: Christian Brabandt <[email protected]>
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.
Following up on my comment here, it seems unnecessary to check
b_locked_split
when "split-moving" windows. It looks like the flag exists to stop new views into a buffer being created while it's closing (which can result in windows into a freed buffer remaining), but split-moving doesn't result in any new views into a buffer, unlike regular splitting.The doc comment for
b_locked_split
also seems to support this:vim/src/structs.h
Lines 3002 to 3003 in 0c98a71
So, continue to check
split_disallowed
when split-moving (it looks possibly relevant), but add a test to check that split-moving is OK whenb_locked_split
is set (I've made sure it crashes Vim if theb_locked_split
check is reverted for regular splitting).Edit: hmm, actually the crash I based the test on has the same backtrace as #13839, which wasn't what I was going for 馃槅.
I was hoping to base it on
Test_autocmd_normal_mess
, which is the test introduced withb_locked_split
, but even that test doesn't seem to crash anymore when reverting theb_locked_split
check for regular splitting...Edit 2: actually, it seems to be a different issue (unrelated to 9.1.0143 or the issue it fixes); it seems
close_buffer
and its callers don't consider that autocmds can make another window view a buffer that's being wiped, without causingb->b_nwindows > 1
.The following crashes Vim with a heap UAF:
I'll try to address this at some point, unless someone beats me to it. 馃槆