Problem: Autocommand may change currect directory after :tcd and :lcd.
Solution: Also clear tp_localdir and w_localdir when using aucmd_win.
(zeertzjq)
closes: #14435
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: winframe functions incorrectly recompute window positions if
the altframe wasn't adjacent to the closed frame, which is
possible if adjacent windows had 'winfix{width,height}' set.
Solution: recompute for windows within the parent of the altframe and
closed frame. Skip this (as before) if the altframe was
top/left, but only if adjacent to the closed frame, as
positions won't change in that case. Also correct the return
value documentation for win_screenpos. (Sean Dewar)
The issue revealed itself after removing the win_comp_pos call below
winframe_restore in win_splitmove. Similarly, wrong positions could result from
windows closed in other tabpages, as win_free_mem uses winframe_remove (at least
until it is entered later, where enter_tabpage calls win_comp_pos).
NOTE: As win_comp_pos handles only curtab, it's possible via other means for
positions in non-current tabpages to be wrong (e.g: after changing 'laststatus',
'showtabline', etc.). Given enter_tabpage recomputes it, maybe it's intentional
as an optimization? Should probably be documented in win_screenpos then, but I
won't address that here.
closes: #14191
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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 <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: more places exist where curwin == prevwin, and it may even be
expected in some cases.
Solution: revert v9.1.0001, but document that it's possible instead.
(Sean Dewar)
I've had a change of heart for the following reasons:
- A quick 'n dirty [GitHub code
search](https://github.com/search?q=%2F%28winnr%5C%28%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%7Cwinnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5C%29%29%2F&type=code)
reveals some cases where it's expected in the wild.
Particularly, it made me aware `winnr() == winnr('#')` is possible when curwin
is changed temporarily during the evaluation of a &statusline expression item
(`%{...}`), and is used to show something different on the statusline
belonging to the previous window; that behaviour wasn't changed in v9.1.0001,
but it means curwin == prevwin makes sense in some cases.
- The definition and call sites of back_to_prevwin imply some expectation that
prevwin == wp (== curwin) is possible, as it's used to skip entering the
prevwin in that case.
- Prior to v9.1.0001, `:wincmd p` would not beep in the case that was patched in
v9.1.0001, but now does. That resulted in #14047 being opened, as it affected
the CtrlP plugin.
I find it odd that `:wincmd p` had cases where it wouldn't beep despite doing
nothing, but it may be preferable to keep things that way (or instead also
beep if curwin == prevwin, if that's preferred).
- After more digging, I found cases in win_free_mem, enter_tabpage,
aucmd_restbuf and qf_open_new_cwindow where curwin == prevwin is possible
(many of them from autocommands). Others probably exist too, especially in
places where curwin is changed temporarily.
fixes: #14047closes: #14186
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Crash in WinClosed after BufUnload closes other windows
Solution: Don't trigger WinClosed if the buffer is NULL (zeertzjq)
Now win_close_othertab() doesn't trigger any autocommands if the buffer
is NULL, so remove the autocmd blocking above (which was added not long
ago in patch v9.0.0550) for consistency.
Also remove an unreachable close_last_window_tabpage() above:
- It is only reached if only_one_window() returns TRUE and last_window()
returns FALSE.
- If only_one_window() returns TRUE, there is only one tabpage.
- If there is only one tabpage and last_window() returns FALSE, the
one_window() in last_window() must return FALSE, and the ONE_WINDOW
in close_last_window_tabpage() must also be FALSE.
- So close_last_window_tabpage() doesn't do anything and returns FALSE.
Then the curtab != prev_curtab check also doesn't make much sense, and
the only_one_window() can be replaced with a check for popup and a call
to last_window() since this is a stricter check than only_one_window().
closes: #14166
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: several minor 'winfixbuf' issues exist, mostly relating to the
quickfix list
Solution: address them and adjust tests. Retab and reflow a few things too.
(Sean Dewar)
Things touched include:
- Replace the semsgs with gettext'd emsgs.
- Handle window switching in ex_listdo properly, so curbuf and curwin
are kept in-sync and trigger autocommands; handle those properly.
- Don't change the list entry index in qf_jump_edit_buffer if we fail
due to 'wfb' (achieved by returning FAIL; QF_ABORT should only be used
if the list was changed).
- Make qf_jump_edit_buffer actually switch to prevwin when using `:cXX`
commands **outside** of the list window if 'wfb' is set in curwin.
Handle autocommands properly in case they mess with the list.
NOTE: previously, it seemed to split if 'wfb' was set, but do nothing
and fail if prevwin is *valid*. This behaviour seemed strange, and maybe
unintentional? Now it aligns more with what's described for the `:cXX`
commands in the original PR description when used outside a list window,
I think.
- In both functions, only consider prevwin if 'wfb' isn't set for it;
fallback to splitting otherwise.
- Use win_split to split. Not sure if there was a specific reason for
using ex_splitview. win_split is simpler and respects modifiers like
:vertical that may have been used. Plus, its return value can be checked
for setting opened_window in qf code (technically win_split_ins autocmds
could immediately close it or change windows, in which the qf code might
close some other window on failure; it's already the case elsewhere,
though).
closes: #14142
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cannot keep a buffer focused in a window
(Amit Levy)
Solution: Add the 'winfixbuf' window-local option
(Colin Kennedy)
fixes: #6445closes: #13903
Signed-off-by: Colin Kennedy <colinvfx@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: autocmd cause use-after-free in set_curbuf()
(kawarimidoll)
Solution: check side-effect of BufLeave autocommand, when the number
of windows changed, close windows containing buffers that will
be wiped, if curbuf changed unexpectedly make sure b_nwindows
is decremented otherwise it cannot be wiped
set_curbuf() already makes some efforts to ensure the BufLeave
autocommands do not cause issues. However there are still 2 issues
that are not taken care of:
1) If a BufLeave autocommand opens a new window containing the same
buffer as that is going got be closed in close_buffer() a bit later,
we suddenly have another window open, containing a free'd buffer. So we
must check if the number of windows changed and if it does (and the
current buffer is going to be wiped (according to the 'bufhidden'
setting), let's immediately close all windows containing the current
buffer using close_windows()
2) If a BufLeave autocommand changes our current buffer (displays it in
the current window), buf->b_nwindow will be incremented. As part of
set_curbuf() we will however enter another buffer soon, which means, the
newly created curbuf will have b_nwindows still have set, even so the
buffer is no longer displayed in a window. This causes later problems,
because it will no longer be possible to wipe such a buffer. So just
before entering the final buffer, check if the curbuf changed when
calling the BufLeave autocommand and if it does (and curbuf is still
valid), decrement curbuf->b_nwindows.
Both issues can be verified using the provided test (however the second
issue only because such an impacted buffer won't be wiped, causing
futher issues in later tests).
fixes: #13839closes: #14104
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: heap-use-after-free in win_splitmove if Enter/Leave
autocommands from win_split_ins immediately closes "wp".
Solution: check that "wp" is valid after win_split_ins.
(Sean Dewar)
closes: #14078
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: infinite loop in win_update with 'smoothscroll' set when
window width is equal to textoff, or signed integer overflow
if smaller.
Solution: don't revalidate wp->w_skipcol in that case, as no buffer text
is being shown. (Sean Dewar)
Don't instead reset w_skipcol; that would lose the scroll position
within the line, which may be undesirable if the window is made wider
later.
Also include changes from the splitmove PR #14042 that I (in my infinite
Git wisdom) forgot to commit. This includes a change to
Test_window_split_no_room to ensure it doesn't fail for some screen
sizes.
Move Test_smoothscroll_in_zero_width_window to test_scroll_opt.vim, as
that file feels more appropriate.
closes: #14068
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: saving and restoring all frames to split-move is overkill now
that WinNewPre is not fired when split-moving.
Solution: defer the flattening of frames until win_split_ins begins
reorganising them, and attempt to restore the layout by
undoing our changes. (Sean Dewar)
This also means we no longer must allocate.
related: #14042
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
Problem: win_split_ins has no check for E36 when moving an existing
window
Solution: check for room and fix the issues in f_win_splitmove()
(Sean Dewar)
win_split_ins has no check for E36 when moving an existing window,
allowing for layouts with many overlapping zero-sized windows to be
created (which may also cause drawing issues with tablines and such).
f_win_splitmove also has some bugs.
So check for room and fix the issues in f_win_splitmove. Handle failure
in the two relevant win_split_ins callers by restoring the original
layout, and factor the common logic into win_splitmove.
Don't check for room when opening an autocommand window, as it's a
temporary window that's rarely interacted with or drawn anyhow, and is
rather important for some autocommands.
Issues fixed in f_win_splitmove:
- Error if splitting is disallowed.
- Fix heap-use-after-frees if autocommands fired from switching to "targetwin"
close "wp" or "oldwin".
- Fix splitting the wrong window if autocommands fired from switching to
"targetwin" switch to a different window.
- Ensure -1 is returned for all errors.
Also handle allocation failure a bit earlier in make_snapshot (callers,
except win_splitmove, don't really care if a snapshot can't be made, so
just ignore the return value).
Note: Test_smoothscroll_in_zero_width_window failed after these changes with
E36, as it was using the previous behaviour to create a zero-width window.
I've fixed the test such that it fails with UBSAN as expected when v9.0.1367 is
reverted (and simplified it too).
related: #14042
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: qsort() comparison functions should be transitive
Solution: Do not subtract values, but rather use explicit comparisons
Improve qsort() comparison functions
There has been a recent report on qsort() causing out-of-bounds read &
write in glibc for non transitive comparison functions
https://www.qualys.com/2024/01/30/qsort.txt
Even so the bug is in glibc's implementation of the qsort() algorithm,
it's bad style to just use substraction for the comparison functions,
which may cause overflow issues and as hinted at in OpenBSD's manual
page for qsort(): "It is almost always an error to use subtraction to
compute the return value of the comparison function."
So check the qsort() comparison functions and change them to be safe.
closes: #13980
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No event is triggered before creating a window.
(Sergey Vlasov)
Solution: Add the WinNewPre event (Sergey Vlasov)
fixes: #10635closes: #12761
Signed-off-by: Sergey Vlasov <sergey@vlasov.me>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Autocmds triggered from opening the cmdwin (in win_split and
do_ecmd) can cause issues such as E199, as the current checks
are insufficient.
Solution: Commands executed from the cmdwin apply to the old curwin/buf,
so they should be kept in a "suspended" state; abort if
they've changed. Also abort if cmdwin/buf was tampered with,
and check that curwin is correct. Try to clean up the cmdwin
buffer (only if hidden and non-current to simplify things; the
same approach is used when closing cmdwin normally), and add a
beep. (Sean Dewar)
It'd be nice to also check that curwin was *really* created by win_split, as
autocommands can change curwin before it returns (so it can't be assumed to be
that of the split); for now, this means that the cmdwin may not be the botwin in
that case, which is probably OK.
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Things that temporarily change/restore curwin/buf (e.g:
win_execute, some autocmds) may break assumptions that
curwin/buf is the cmdwin when "cmdwin_type != 0", causing
issues.
Solution: Expose the cmdwin's real win/buf and check that instead. Also
try to ensure these variables are NULL if "cmdwin_type == 0",
allowing them to be used directly in most cases without
checking cmdwin_type. (Sean Dewar)
Alternatively, we could ban win_execute in the cmdwin and audit all places that
temporarily change/restore curwin/buf, but I didn't notice any problems arising
from allowing this (standard cmdwin restrictions still apply, so things that may
actually break the cmdwin are still forbidden).
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Insert mode not stopped if an autocommand modifies a hidden
buffer while closing a prompt buffer.
Solution: Don't set b_prompt_insert if stop_insert_mode is already set.
(zeertzjq)
closes: #13872
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: cmdline may disappear when changing 'cmdheight'
(after Patch 9.0.0190, @markonm)
Solution: always re-calculate the old_p_ch value, not only
when cmdline_row was higher than expected
fixes: #13822closes: #13826
Signed-off-by: Christian Brabandt <cb@256bit.org>
Avoid `prevwin == curwin` when closing `curwin`
Problem: When closing the current window (or when moving it to a tabpage), the
previous window may refer to the new current window
(`winnr() == winnr('#')`) if that window is selected as the
new current window.
Solution: Set `prevwin = NULL` when switching away from an invalid `curwin` and
the target window was the `prevwin`.
(Sean Dewar)
related: #4537closes: #13762
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Moving tabpages on :drop may cause an endless loop
Solution: Disallow moving tabpages on :drop when cleaning up the arglist
first
Moving tabpages during drop command may cause an endless loop
When executing a :tab drop command, Vim will close all windows not in
the argument list. This triggers various autocommands. If a user has
created an 'au Tabenter * :tabmove -' autocommand, this can cause Vim to
end up in an endless loop, when trying to iterate over all tabs (which
would trigger the tabmove autocommand, which will change the tpnext
pointer, etc).
So instead of blocking all autocommands before we actually try to edit
the given file, lets simply disallow to move tabpages around. Otherwise,
we may change the expected number of events triggered during a :drop
command, which users may rely on (there is actually a test, that expects
various TabLeave/TabEnter autocommands) and would therefore be a
backwards incompatible change.
Don't make this an error, as this could trigger several times during the
drop command, but silently ignore the :tabmove command in this case (and
it should in fact finally trigger successfully when loading the given
file in a new tab). So let's just be quiet here instead.
fixes: #13676closes: #13686
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in win-enter
Solution: validate window pointer before calling win_enter()
win_goto() may stop visual mode, if it is active. However, this may in
turn trigger the ModeChanged autocommand, which could potentially free
the wp pointer which was valid before now became stale and points to now
freed memory.
So before calling win_enter(), let's verify one more time, that the
wp pointer still points to a valid window structure.
Reported by @henices, thanks!
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: ml_get error when scrolling after delete
Solution: mark topline to be validated in main_loop
if it is larger than current buffers line
count
reset_lnums() is called after e.g. TextChanged autocommands and it may
accidentally cause curwin->w_topline to become invalid, e.g. if the
autocommand has deleted some lines.
So verify that curwin->w_topline points to a valid line and if not, mark
the window to have w_topline recalculated in main_loop() in
update_topline() after reset_lnums() returns.
fixes: #13568fixes: #13578
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: crash with bt_quickfix1_poc when cleaning up
and EXITFREE is defined
Solution: Test if buffer is valid in a window, else close
window directly, don't try to access buffer properties
While at it, increase the crash timeout slightly, so that CI has a
chance to finish processing the test_crash() test.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cursor is adjusted in window that did not change in size by
'splitkeep'.
Solution: Only check that cursor position is valid in a window that
has changed in size.
closes: #12509
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem: incorrect heights in win_size_restore()
Solution: avoid restoring incorrect heights in win_size_restore()
Changing 'showtabline' or 'cmdheight' in the cmdwin restores incorrect
window heights after closing the cmdwin.
This may produce a gap between the cmdline and the window above.
Solution: restore window sizes only if the number of lines available for windows
changed; subtract the rows of the tabline, cmdline and last window's statusline
from 'lines' (other statuslines don't matter).
closes: #12704
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Problem: sidescrolloff and scrolloff options work slightly
different than other global-local options
Solution: Make it behave consistent for all global-local options
It was noticed, that sidescrolloff and scrolloff options behave
differently in comparison to other global-local window options like
'listchars'
So make those two behave like other global-local options. Also add some
extra documentation for a few special local-window options.
Add a few tests to make sure all global-local window options behave
similar
closes: #12956closes: #12643
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cursor not adjusted when near top or bottom of window and
'splitkeep' is not "cursor".
Solution: Move boundary checks to outer cursor move functions, inner
functions should only return valid cursor positions. (Luuk van
Baal, closes#12480)
Problem: RedrawingDisabled not used consistently.
Solution: Avoid RedrawingDisabled going negative. Set RedrawingDisabled in
win_split_ins(). (closes#11961)
Problem: Some commands for opening a file don't use 'switchbuf'.
Solution: Use 'switchbuf' for more commands. (Yegappan Lakshmanan,
closes#12383, closes#12381)
Problem: FOR_ALL_ macros are defined in an unexpected file.
Solution: Move FOR_ALL_ macros to macros.h. Add FOR_ALL_HASHTAB_ITEMS.
(Yegappan Lakshmanan, closes#12109)
Problem: Status line of other window not redrawn when dragging it when
'splitkeep' is set to "screen".
Solution: Set w_redr_status earlier. (Luuk van Baal, closes#11635,
closes#11632)
