Problem: Arbitrary restriction on 'cmdheight' with ext_messages.
The 'cmdheight'-area may be desirable for the replacing
cmdline.
Solution: Allow non-zero 'cmdheight' with ext_messages.
Problem: may not be clear why failing to split causes an ":Xdo" command
to abort if 'wfb' is set.
Solution: do not return immediately if win_split fails, so E1513 is
still given. Expect both errors in the test. Also fix tests to
pass CI.
(Sean Dewar)
closes: vim/vim#14152769eb2d0c3
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: Coverity complains about ignoring return value of win_split()
(after v9.1.150)
Solution: Check if win_split() failed, add winfixbuf.res to Makefile
af7ae81600
Co-authored-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: vim/vim#141424bb505e28c
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: qf_goto_win_with_qfl_file may check if prevwin has 'winfixbuf'
set without checking if it's valid first.
Solution: Reverse the condition. Add a test, a modeline, and a missing
CheckFeature. (Searn Dewar)
closes: vim/vim#141405131f224da
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
`get_target_property(<var> ...)` sets `<var>` to `<var>-NOTFOUND` if the
property doesn't exist for the given target. Detect this situation to
avoid adding various `-Dprop-NOTFOUND` and `-Iprop-NOTFOUND` to the
command-line when generating the headers.
Problem: Internal error or crash when passing invalid position to
getregion().
Solution: Give an error for invalid position (zeertzjq).
closes: vim/vim#1417226dd09ad5e
Problem: too many STRLEN calls when getting a memline
Solution: Optimize calls to STRLEN(), add a few functions in memline.c
that return the byte length instead of relying on STRLEN()
(John Marriott)
closes: vim/vim#1405202d7a6c6cf
Cherry-pick line break changes from patch 8.1.0226.
Cherry-pick ml_line_len from patch 8.1.0579.
Cherry-pick test_comments.vim change from patch 9.1.0153.
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: problem with writing extended attributes on failure
Solution: Change return type to ssize_t and check listxattr's return
value correctly on failure (Paul Tagliamonte)
The existing logic will return when the listxattr call returns with the
errno set to ENOTSUP (or a size of 0 bytes), without checking to see if
listxattr actually failed. listxattr can fail with at least E2BIG,
ENOTSUP, ERANGE, or anything that `stat(2)` can fail with (in my case;
ENOENT from stat).
The returned size is stored to a size_t, but the return type is a
ssize_t. On failure, listxattr returns -1, which will get translated to
size_t's MAX. If the listxattr call failed with anything other than
ENOTSUP, this triggers a request for size_t MAX bytes.
This means that, if the listxattr call fails with anything other than
ENOTSUP on save, vim will error with
`E342: Out of memory! (allocating 18446744073709551615 bytes)`
(keen observers will note 18446744073709551615 is 0xffffffffffffffff)
In reality, this is likely masking a different (usually filesystem?)
error -- but at least it's an error being pushed to the user now, and we
don't try to allocate size_t MAX bytes.
I've opted to change the type that we store listxattr to from size_t to
ssize_t, to match listxattr(2)'s signature, and to check for the -1
return value. Additionally, I've removed the errno check -- if we get a
listxattr failure for any reason, we may as well bail without trying;
it's not like we can even recover.
closes: vim/vim#1416914759ded57
Co-authored-by: Paul R. Tagliamonte <paultag@gmail.com>
runtime(vim): Update base-syntax, improve :menu{,translate} highlighting (vim/vim#14162)
Improve :menu and :menutranslate highlighting.
- Match args to :menutranslation and :popup.
- Only highlight special notation in {rhs} of :menu, like :map.
- Allow line continuations in {rhs} of :menu and between {english} and
{mylang} of :menutranslation, matching common usage.
- Bug fixes.
62b26040eb
Co-authored-by: dkearns <dougkearns@gmail.com>
runtime(java): Recognise string templates (vim/vim#14150)
As this is encouraged in the referenced JEPs, "to visually
distinguish a string template from a string literal, and
a text block template from a text block", the default
colours for java\%[Debug]StrTempl are made distinct from
java\%[Debug]String.
According to §3.2 Lexical Translations (JLS, c. 1996 or any
more recent version), line terminators, white space, and
comments are discarded before tokens are accepted. Since
a template expression comprises a template processor, a dot,
and a template, it may be visually appealing to break up
its head across a few lines whenever its tail already spans
multiple lines. Curiously, no allowance for it is made in
the distributed tests for OpenJDK 21; the proposed regexp
patterns take in consideration a line terminator and white
space after a dot.
References:
https://openjdk.org/jeps/430 (Preview)
https://openjdk.org/jeps/459 (Second Preview)
https://openjdk.org/jeps/465a2c65809da
Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
This reverts PR #27793.
On second thought, this solution may still crash, because it can leave a
window with a NULL buffer if there are autocommand windows or if closing
a floating window fails. It also makes close_last_window_tabpage() more
complicated, so revert it.
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: vim/vim#14166b2ec0da080
Problem: expand() removes a slash after an environment variable that
ends with a colon on Windows.
Solution: Check the correct char for a colon (zeertzjq)
closes: vim/vim#14161
Note: Vim still removes the path-separator at the end, if another path separator
follows directly after it, e.g. on:
```
echo $FOO='/usr/'
echo expand('$FOO/bar') == '/usr/bar'
```
see:
,----[ misc1.c:1630 ]
| // if var[] ends in a path separator and tail[] starts
| // with it, skip a character
| if (after_pathsep(dst, dst + c)
| #if defined(BACKSLASH_IN_FILENAME) || defined(AMIGA)
| && (dst == save_dst || dst[-1] != ':')
| #endif
| && vim_ispathsep(*tail))
| ++tail;
`----
13a014452a
Cherry-pick test_expand.vim change from patch 9.0.1257.
Problem: Crash on exit with EXITFREE and using win_execute().
Solution: Also save and restore tp_topframe. (issue vim/vim#9374)
dab17a0689
Couldn't repro the crash in the test, but I only care about this patch so
switch_win sets topframe properly for win_split_ins in nvim_open_win and
nvim_win_set_config.
Add a test using nvim_win_call and :wincmd, as I couldn't repro the issue via
nvim_open_win or nvim_win_set_config (though it's clear they're affected by this
patch).
That said, at that point, could just use {un}use_tabpage inside switch_win
instead, which also updates tp_curwin (though maybe continue to not set it in
restore_win). That would also fix possible inconsistent behaviour such as:
:call win_execute(w, "let curwin_nr1 = tabpagewinnr(1)")
:let curwin_nr2 = tabpagewinnr(1)
Where it's possible for curwin_nr1 != curwin_nr2 if these commands are run from
the 1st tabpage, but window "w" is in the 2nd (as the 1st tabpage's tp_curwin
may still be invalid). I'll probably PR a fix for that later in Vim.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: nvim_win_set_config does not update the tp_curwin of win's original
tabpage when moving it to another.
Solution: update it if win was the tp_curwin. Add a test.
Problem: illegal memory access when completing with invalid bytes.
Solution: Avoid going over the end of the completion text.
vim/vim@4b28ba3
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem Description: In ex_mode, the default_grid.chars are not allocated, and subsequently,
the w_grid.target in curwin is not allocated to default_grid in update_screen. This leads to
a null pointer crash when the completion function is executed in ex_mode.
Solution: Set full_screen when in ex_mode to ensure that default_grid is allocated.
Problem: :close may cause Nvim to quit if an autocommand triggered when
closing the buffer closes all other non-floating windows and
there are floating windows.
Solution: Correct the check for the only non-floating window.
Its corresponding test in Vim is in test_popupwin.win, so having it in
the middle of test_window_cmd.vim is strange, and it is now covered by
tests in ui/float_spec.lua anyway.
Problem: nvim_win_set_config does not update statuslines after removing a split.
Solution: call last_status.
Didn't realize this was missing in the original nvim_win_set_config for splits
PR.
As it can only be done for the current tabpage, do it if win_tp == curtab;
enter_tabpage will eventually call last_status anyway when the user enters
another tabpage.
Problem: there are new ways to escape textlock or break the cmdwin in
nvim_win_set_config and nvim_tabpage_set_win.
Solution: fix them. Use win_goto to check it in nvim_tabpage_set_win and use the
try_start/end pattern like with similar functions such as nvim_set_current_win
(which uses the existing msg_list, if set).
Careful not to use `wp->handle` when printing the window ID in the error message
for nvim_tabpage_set_win, as win_goto autocommands may have freed the window.
On a related note, I have a feeling some API functions ought to be checking
curbuf_locked...
Problem: nvim_win_set_config does not handle failure in win_split_ins properly
yet, which can cause all sorts of issues. Also nvim_open_win and
nvim_win_set_config do not set the error message to the one from win_split_ins.
Solution: handle failure by undoing winframe_remove, like in win_splitmove.
Make sure autocommands from switching to the altwin fire within a valid window,
and ensure they don't screw things up. Set the error message to that of
win_split_ins, if any.
Also change a few other small things, including:
- adjust win_append to take a tabpage_T * argument, which is more consistent
with win_remove (and also allows us to undo a call to win_remove).
- allow winframe_restore to restore window positions. Useful if `wp` was in a
different tabpage, as a call to win_comp_pos (which only works for the current
tabpage) after winframe_restore should no longer be needed.
Though enter_tabpage calls win_comp_pos anyway, this has the advantage of
ensuring w_winrow/col remains accurate even before entering the tabpage
(useful for stuff like win_screenpos, if used on a window in another tabpage).
(This change should probably also be PR'd to Vim later, even though it doesn't
use winframe_restore for a `wp` in a different tabpage yet).
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)
abf7030a5c
Problem: win_gotoid() checks for textlock and other things when switching
to a window that is already current (after v9.1.0119)
Solution: return early with success when attempting to switch to curwin
(Sean Dewar)
2a65e73944
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)
02fcae02a9
Test_window_split_no_room changes were already cherry-picked earlier.
Problem: can switch windows while textlocked via f_win_gotoid and
f_win_splitmove (which also allows switching in the cmdwin).
Solution: Check text_or_buf_locked in f_win_splitmove()
(Sean Dewar)
While at it, call text_or_buf_locked() in f_win_gotoid() instead of testing for
cmdwin_type() (which text_buf_locked() does and in addition will also verify
that the buffer is not locked).
f865895c87
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)
704966c254
Adjust winframe_restore to account for Nvim's horizontal separators when the
global statusline is in use. Add a test.
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)
96cc4aef3d
Partial as WinNewPre has not been ported yet (it currently has problems anyway).
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)
0fd44a5ad8
Omit WSP_FORCE_ROOM, as it's not needed for Nvim's autocmd window, which is
floating. Shouldn't be difficult to port later if it's used for anything else.
Make win_splitmove continue working for turning floating windows into splits.
Move the logic for "unfloating" a float to win_split_ins; unlike splits, no
changes to the window layout are needed before calling it, as floats take no
room in the window layout and cannot affect the e_noroom check.
Add missing tp_curwin-fixing logic for turning external windows into splits, and
add a test.
NOTE: there are other issues with the way "tabpage independence" is implemented
for external windows; namely, some things assume that tp_curwin is indeed a
window within that tabpage, and as such, functions like tabpage_winnr and
nvim_tabpage_get_win currently don't always work for external windows (with the
latter aborting!)
Use last_status over frame_add_statusline, as Nvim's last_status already does
this for all windows in the current tabpage. Adjust restore_full_snapshot_rec to
handle this.
This "restore everything" approach is changed in a future commit anyway, so only
ensure it's robust enough to just pass tests.
Keep check_split_disallowed's current doc comment, as it's actually a bit more
accurate here. (I should probably PR Vim to use this one)
Allow f_win_splitmove to move a floating "wp" into a split; Nvim supports this.
Continue to disallow it from moving the autocommand window into a split (funnily
enough, the check wasn't reachable before, as moving a float was disallowed),
but now return -1 in that case (win_splitmove also returns FAIL for this, but
handling it in f_win_splitmove avoids us needing to switch windows first).
Cherry-pick Test_window_split_no_room fix from v9.1.0121.
Update nvim_win_set_config to handle win_split_ins failure in later commits.
Problem: nvim_open_win blocking all win_set_buf autocommands when !enter &&
!noautocmd is too aggressive.
Solution: temporarily block WinEnter/Leave and BufEnter/Leave events when
setting the buffer. Delegate the firing of BufWinEnter back to win_set_buf,
which also has the advantage of keeping the timing consistent (e.g: before the
epilogue in enter_buffer, which also handles restoring the cursor position if
autocommands didn't change it, among other things). Reword the documentation for
noautocmd a bit.
I pondered modifying do_buffer and callees to allow for BufEnter/Leave being
conditionally disabled, but it seems too invasive (and potentially error-prone,
especially if new code paths to BufEnter/Leave are added in the future).
Unfortunately, doing this has the drawback of blocking ALL such events for the
duration, which also means blocking unrelated such events; like if window
switching occurs in a ++nested autocmd fired by win_set_buf. If this turns out
to be a problem in practice, a different solution specialized for nvim_open_win
could be considered. :-)
Problem: currently, for splits, nvim_win_set_config accepts win without any of
split or vertical set, which has little effect and seems error-prone.
Solution: require at least one of split or vertical to also be set for splits.
Also, update nvim_win_set_config docs, as it's no longer limited to just
floating and external windows.
Problem: splitting is disallowed in some cases to prevent the window layout
changes while a window is closing, but it's not checked for.
Solution: check for this, and set the API error message directly.
(Also sneak in a change to tui.c that got lost from #27352; it's a char* buf,
and the memset is assuming one byte each anyway)
