diff options
author | Sean Dewar <6256228+seandewar@users.noreply.github.com> | 2024-02-20 21:52:31 +0100 |
---|---|---|
committer | Christian Brabandt <cb@256bit.org> | 2024-02-20 21:52:31 +0100 |
commit | 96cc4aef3d47d0fd70e68908af3d48a0dce8ea70 (patch) | |
tree | c03c09e722515ed74ceea5e43e220334e0ec38af /src/window.c | |
parent | 0fd44a5ad81ade342cb54d8984965bdedd2272c8 (diff) |
patch 9.1.0117: Stop split-moving from firing WinNew and WinNewPre autocommandsv9.1.0117
Problem: win_splitmove fires WinNewPre and possibly WinNew when moving
windows, even though no new windows are created.
Solution: don't fire WinNew and WinNewPre when inserting an existing
window, even if it isn't the current window. Improve the
accuracy of related documentation. (Sean Dewar)
Likewise, before this patch, WinClosed was not fired anyway (even for :wincmd
H/J/K/L, which also didn't fire WinNew, but did still fire WinNewPre), despite
documentation saying windows are "closed". Note that :wincmd T actually indeed
works by creating a new window (and closing the old one), unlike the others.
This also fixes issues where WinNewPre is fired when split-moving while curwin
doesn't yet have a frame or entry in the window list, causing many things to not
work (it's not considered valid at that point). This was guaranteed when using
:wincmd H/J/K/L.
Because WinNewPre is no longer fired when split-moving, this makes restoring the
previous window layout on failure easier, as we can be sure that frames are not
resized from WinNewPre autocommands if win_split_ins fails. This allows us to
use a different strategy in the following commit.
--
In my opinion, this leaves questions about the current usefulness of WinNewPre.
A motivation described in #10635 states how creating a new window can steal room
from other windows, and how WinNewPre will be useful for detecting that, but
this is also true when inserting an existing window, which now doesn't fire it.
Maybe the autocommand should be changed to have a better name?
There are also other issues I found with the current implementation of WinNewPre
that need addressing:
- it allows switching windows and tabpages, which can cause incorrect windows to
be split/moved, and big problems when switching tabpages.
- it fires before win_split_ins checks for room, before it makes any changes to
window sizes or before it considers allocating a new window. This should be
changed or documented.
I hope to address some of this stuff in a different PR, if possible.
related: #14038
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Diffstat (limited to 'src/window.c')
-rw-r--r-- | src/window.c | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/src/window.c b/src/window.c index de43476650..1ae7b27d8f 100644 --- a/src/window.c +++ b/src/window.c @@ -935,6 +935,8 @@ win_split(int size, int flags) * When "new_wp" is NULL: split the current window in two. * When "new_wp" is not NULL: insert this window at the far * top/left/right/bottom. + * On failure, if "new_wp" was not NULL, no changes will have been made to the + * window layout or sizes. * Return FAIL for failure, OK otherwise. */ int @@ -964,7 +966,8 @@ win_split_ins( // Do not redraw here, curwin->w_buffer may be invalid. ++RedrawingDisabled; - trigger_winnewpre(); + if (new_wp == NULL) + trigger_winnewpre(); if (flags & WSP_TOP) oldwin = firstwin; @@ -1444,7 +1447,7 @@ win_split_ins( /* * make the new window the current window */ - (void)win_enter_ext(wp, WEE_TRIGGER_NEW_AUTOCMDS + (void)win_enter_ext(wp, (new_wp == NULL ? WEE_TRIGGER_NEW_AUTOCMDS : 0) | WEE_TRIGGER_ENTER_AUTOCMDS | WEE_TRIGGER_LEAVE_AUTOCMDS); if (flags & WSP_VERT) p_wiw = i; |