Problem:
cmdwin (the `:q` cmdline buffer) has various limitations which require
special-casing all over the codebase.
Besides complicating the code, it also breaks async plugins if they try
to create buffers/windows after some work is done, if the user happens
to open cmdwin at the wrong the moment:
Lua callback: …/guh.nvim/lua/guh/util.lua:531:
E11: Invalid in command-line window; <CR> executes, CTRL-C quits
stack traceback:
[C]: in function 'nvim_buf_delete'
…/guh.nvim/lua/guh/util.lua:531: in function <…/guh.nvim/lua/guh/util.lua:526>
Solution:
Just say no to "inception". Reimplement cmdwin as a normal buffer+window.
All of the cmdwin contortions (in both core, and innocent plugins) exist
literally only to support "inception": recursive
cmdwin-in-cmdline-things, like `<c-r>=`, `/`, search-during-substitute,
`:input()`, etc. So we just won't support that (though I have
a potential plan for that later, which I call "modal parking lot").
The benefit is that plugins, and core, no longer have to care about
cmdwin.
BONUS:
- mouse-drag on vertical separators works (it only worked for
horizontal/statusline before)
- inccommand-in-cmdwin now works correctly, for free (thus don't need
#40077).
POTENTIAL FOLLOWUPS
- Drop `CHECK_CMDWIN` ("E11: Invalid in command-line window"), allow chaos.
- Unify `BUFLOCK_OK` / `LOCK_OK` ?
DESIGN:
- Eliminate lots of C globals, `EX_CMDWIN`, etc.
- `text_locked()` no longer reports true for cmdwin.
- cmdwin = a normal window with 'winfixbuf', 'bufhidden=wipe',
'buftype=nofile'. Invariants come from those options rather than
special cases throughout the codebase.
- `nv_record` for q:/q//q? calls Lua
`nlua_call_vimfn("vim._core.cmdwin", …)`. No `K_CMDWIN`
/ cmdline-reader detour.
- `cedit_key` (`c_CTRL-F`) schedules a deferred event that calls
`vim._core.cmdwin.open(type, content, pos)` and returns `Ctrl_C` so
the in-flight cmdline cancels. Reader state is not serialized; instead
the captured `(type, line, col)` is replayed via
`nvim_feedkeys(type..line.."<CR>", "nt", …)` after user confirms.
- On confirm/cancel: `<CR>` / `<C-C>` calls into Lua which closes the
window and re-feeds the cmdline.
BREAKING CHANGES:
- Expression-register cmdline (`<C-R>=` from insert-mode) no longer
supports cmdwin. Same applies to `input()` / `inputlist()` (already
covered by `text_locked`).
- Usage of cmdwin in macros/mappings will probably break (assuming they
ever worked).
Problem: nvim_open_tabpage's "enter" argument is optional, which is inconsistent
with nvim_open_win.
Solution: make it a (non-optional) positional argument, like nvim_open_win.
Also change "enter"'s description to be more like nvim_open_win's doc.
Problem: "after" in nvim_open_tabpage is inconsistent with how a count works
with :tab, :tabnew, etc. Plus, the name "after" implies it's inserted after that
number.
Solution: internally offset by 1. Allow negative numbers to mean after current.
Hmm, should we even reserve sentinels for after current? Callers can probably
just use nil...
- Cleanup, remove redundant comments, add more tests.
- Enhance win_new_tabpage rather than create a new function for !enter, and use
a different approach that minimizes side-effects. Return the tabpage_T * and
first win_T * it allocated.
- Disallow during textlock, like other APIs that open windows.
- Remove existing win_alloc_firstwin error handling from win_new_tabpage; it's
not needed, and looks incorrect. (enter_tabpage is called for curtab, which is
not the old tabpage! Plus newtp is not freed)
- Fix checks after creating the tabpage:
- Don't fail if buf wasn't set successfully; the tab page may still be valid
regardless. Set buffer like nvim_open_win, possibly blocking Enter/Leave
events. (except BufWinEnter)
- tp_curwin may not be the initial window opened by win_new_tabpage. Use the
win_T * it returns instead, which is the real first window it allocated,
regardless of autocmd shenanigans.
- Properly check whether tab page was freed; it may have also been freed
before win_set_buf. Plus, it may not be safe to read its handle!
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
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...
- Rename `meth_pcall`.
- Make `pcall_err` raise an error if the function does not fail.
- Add `vim.pesc()` to treat a string as literal where a Lua pattern is
expected.
msgpack_rpc_to_object (called by handle_request .. msgpack_rpc_to_array)
always NUL-terminates API Strings.
But handle_request .. msgpack_rpc_get_handler_for operates on a raw
msgpack_object, before preparation.
Also re-word some error messages:
- "Key does not exist: %s"
- "Invalid channel: %<PRIu64>"
- "Request array size must be 4 (request) or 3 (notification)"
- "String cannot contain newlines"
References #6150
In order to provide better compatibility with the classic bindings, the
API needs to provide the ability to query the number (really index) of
the window/tabpage.
This is needed for neovim/python-client#87, as discussed in
neovim/neovim#1898.
Signed-off-by: James McCoy <jamessan@jamessan.com>
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
Sanity API checks made by the python-client in the api-python travis target were
converted to lua and will now live in this repository. This will simplify
performing breaking changes to the API as it won't be necessary to send parallel
PRs the python-client.
