Commit Graph

29125 Commits

Author SHA1 Message Date
Tomas Slusny
0f20b7d803 docs: adjust fswatch overflow message to mention docs with info
- Add :h fswatch-limitations that notifies user about default inotify
  limitations on linux and how to adjust them
- Check for Event queue overflow message from fswatch and refer user to
  new documentation

Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
2024-03-11 14:05:26 +00:00
Lewis Russell
cdbc3e3f3e fix(editorconfig): syntax error regression 2024-03-11 10:06:57 +00:00
Christian Clason
f879a65455 build(deps): bump luajit to HEAD - d06beb048 2024-03-11 16:45:20 +08:00
Luuk van Baal
b72931e704 feat(ui): allow non-zero 'cmdheight' with ext_messages
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.
2024-03-11 07:13:48 +01:00
zeertzjq
3814750d37
Merge pull request #27738 from ColinKennedy/vim-9.1.0147
vim-patch:9.1.{0147,0149,0150,0152,0156},58f1e5c0893a: 'winfixbuf'
2024-03-11 12:05:01 +08:00
zeertzjq
3b3511c4d9 vim-patch:9.1.0156: Make 'wfb' failing to split still report E1513
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#14152

769eb2d0c3

Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
2024-03-11 11:42:03 +08:00
zeertzjq
d71791a11a vim-patch:9.1.0152: Coverity complains about ignoring return value
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>
2024-03-11 11:38:15 +08:00
Colin Kennedy
5931f2bc4a vim-patch:9.1.0150: Several minor 'winfixbuf' issues
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#14142

4bb505e28c

Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
2024-03-11 11:38:15 +08:00
Colin Kennedy
e8bc23db62 vim-patch:9.1.0149: null pointer member access when accessing 'winfixbuf' property
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#14140

5131f224da

Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
2024-03-11 11:38:15 +08:00
Colin Kennedy
141182d6c6 vim-patch:9.1.0147: Cannot keep a buffer focused in a window
Problem:  Cannot keep a buffer focused in a window
          (Amit Levy)
Solution: Add the 'winfixbuf' window-local option
          (Colin Kennedy)

fixes:  vim/vim#6445
closes: vim/vim#13903

2157035637

N/A patch:
vim-patch:58f1e5c0893a
2024-03-11 11:38:13 +08:00
James McCoy
118fd8367c
fix: deduplicate gen_cflags
Since many of the targets have common include paths, `gen_cflags`
accumulates a lot of duplicate flags.
2024-03-10 20:02:32 -04:00
James McCoy
74b2f6c3d9
fix: ignore non-existent properties during header generation
`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.
2024-03-10 19:58:35 -04:00
Lewis Russell
a09ddd7ce5 docs(editorconfig): move to source 2024-03-10 23:20:44 +00:00
Riley Bruins
09a919f313 docs: more accurate typing for vim.tbl_extend 2024-03-10 23:20:26 +00:00
zeertzjq
47942db307
vim-patch:675cbfb47f03 (#27806)
runtime(doc): Update Markdown syntax, add missing configs

fixes: vim/vim#14168

675cbfb47f

Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-03-11 06:41:53 +08:00
zeertzjq
92d4dbbd8c
vim-patch:9.1.0164: Internal error when passing invalid position to getregion() (#27805)
Problem:  Internal error or crash when passing invalid position to
          getregion().
Solution: Give an error for invalid position (zeertzjq).

closes: vim/vim#14172

26dd09ad5e
2024-03-11 06:21:32 +08:00
Oscar Creator
06fcf71bd0 fix(fswatch): --latency is locale dependent 2024-03-10 19:50:32 +00:00
zeertzjq
b465ede2c7
vim-patch:9.1.0138: too many STRLEN calls when getting a memline (#27799)
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#14052

02d7a6c6cf

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>
2024-03-10 17:08:00 +08:00
zeertzjq
a441bdc936
vim-patch:9.1.0162: problem with writing extended attributes on failure (#27800)
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#14169

14759ded57

Co-authored-by: Paul R. Tagliamonte <paultag@gmail.com>
2024-03-10 16:58:01 +08:00
zeertzjq
8797429a7a
Merge pull request #27798 from zeertzjq/vim-62b26040eb4b
vim-patch: update Vim syntax
2024-03-10 11:30:24 +08:00
zeertzjq
b5f870cf12 vim-patch:5d67aef3060d
runtime(vim): Update base-syntax, improve :map highlighting (vim/vim#14141)

Improve :map command highlighting.

- Fix multiline RHS matching, allow continued lines and comments.
- Allow ^V-escaped whitespace in LHS.
- Handle map-bar properly and allow trailing commands.

Fixes issue vim/vim#12672.

5d67aef306

Co-authored-by: dkearns <dougkearns@gmail.com>
2024-03-10 10:39:43 +08:00
zeertzjq
84b6ae82c7 vim-patch:62b26040eb4b
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>
2024-03-10 10:39:43 +08:00
Christian Clason
3c66e285cc vim-patch:a2c65809dafe
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/465

a2c65809da

Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
2024-03-10 10:36:26 +08:00
zeertzjq
6052b346f1
revert: "fix(window): :close crash with autocmd, floats and tabpage" (#27796)
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.
2024-03-10 10:33:10 +08:00
zeertzjq
9bd4a28079
fix(window): :close crash if WinClosed from float closes window (#27794)
Problem:  :close crash if WinClosed from float closes window.
Solution: Check if window has already been closed.
2024-03-10 08:37:16 +08:00
zeertzjq
731e7f51ee
fix(window): :close crash with autocmd, floats and tabpage (#27793)
Problem:  :close crash with autocmd, floats and tabpage.
Solution: Close floating windows in one more case.
2024-03-10 07:55:04 +08:00
zeertzjq
448cf10c47
vim-patch:9.1.0159: Crash in WinClosed after BufUnload closes other windows (#27792)
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#14166

b2ec0da080
2024-03-10 07:03:36 +08:00
zeertzjq
241c161299
vim-patch:9.1.0161: expand() removes slash after env variable that ends with colon (#27791)
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.
2024-03-10 06:47:09 +08:00
Sean Dewar
b596732831
Merge pull request #27330 from seandewar/win_set_config-fixes
fix(api): various window-related function fixes

This is a big one!
2024-03-09 22:32:20 +00:00
Sean Dewar
c3d22d32ee
vim-patch:8.2.3862: crash on exit with EXITFREE and using win_execute()
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>
2024-03-09 21:58:30 +00:00
Sean Dewar
b52d15853e
fix(api): win_set_config set tp_curwin of win moved from other tabpage
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.
2024-03-09 18:00:30 +00:00
Lewis Russell
ade1b12f49 docs: support inline markdown
- Tags are now created with `[tag]()`
- References are now created with `[tag]`
- Code spans are no longer wrapped
2024-03-09 11:21:55 +00:00
Raphael
0e28493914
vim-patch:8.2.3915: illegal memory access when completing with invalid bytes (#27491)
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>
2024-03-09 19:21:31 +08:00
bfredl
9eda2f2495
Merge pull request #27764 from glepnir/grid_null
fix: set full_screen when in ex_mode
2024-03-09 11:52:42 +01:00
glepnir
b21d960119 fix(startup): set full_screen when in ex_mode
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.
2024-03-09 18:20:59 +08:00
dundargoc
649dd00fe2 feat!: remove deprecated functions 2024-03-09 10:54:24 +01:00
zeertzjq
33dfb5a383 fix(window): :close may cause Nvim to quit with autocmd and float
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.
2024-03-09 13:38:32 +08:00
zeertzjq
6416c6bc94 test(old): remove Test_floatwin_splitmove()
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.
2024-03-09 12:27:20 +08:00
Sean Dewar
54022a2946
fix(api): win_set_config update statuslines after removing splits
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.
2024-03-09 01:00:33 +00:00
Sean Dewar
e7c262f555
fix(api): patch some cmdwin/textlock holes
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...
2024-03-08 23:24:06 +00:00
Sean Dewar
d942c2b943
fix(api): handle win_split_ins failure properly
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).
2024-03-08 23:24:05 +00:00
Sean Dewar
832bc5c169
vim-patch:9.1.0130: [security]: UAF if win_split_ins autocommands delete "wp"
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
2024-03-08 23:24:05 +00:00
Sean Dewar
e3d4dfb6c3
vim-patch:9.1.0128: win_gotoid() may abort even when not switching a window
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
2024-03-08 23:24:05 +00:00
Sean Dewar
b2245307f2
vim-patch:9.1.0121: Infinite loop or signed overflow with 'smoothscroll'
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.
2024-03-08 23:24:05 +00:00
Sean Dewar
01b27410a3
vim-patch:9.1.0119: can move away from cmdwin using win_splitmove()
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
2024-03-08 23:24:05 +00:00
Sean Dewar
1c6b693ec1
vim-patch:9.1.0118: Use different restoration strategy in win_splitmove
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.
2024-03-08 23:24:04 +00:00
Sean Dewar
24dfa47e4f
vim-patch:partial:9.1.0117: Stop split-moving from firing WinNew and WinNewPre autocommands
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).
2024-03-08 23:24:04 +00:00
Sean Dewar
66f331fef7
vim-patch:9.1.0116: win_split_ins may not check available room
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.
2024-03-08 23:24:04 +00:00
Sean Dewar
a70eae57bd
fix(api): make open_win block only enter/leave events if !enter && !noautocmd
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. :-)
2024-03-08 23:24:04 +00:00
Sean Dewar
b1577d371a
fix(api): make win_set_config with "win" for splits need "split/vertical"
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.
2024-03-08 23:24:04 +00:00