summaryrefslogtreecommitdiffstatshomepage
path: root/test/functional/vimscript/api_functions_spec.lua
AgeCommit message (Collapse)AuthorFiles
2026-04-20refactor(test): drop deprecated exc_exec #39242Justin M. Keyes1
2025-07-11vim-patch:6ac2e4a: runtime(vim): Update base syntax, improve function call ↵zeertzjq1
highlighting (#34874) - Match more function calls. - Contain function call syntax groups. - Improve differentiation between Ex commands and builtin functions with the same name. Remove special cases. Command modifiers are not currently well differentiated from functions. closes: vim/vim#17712 https://github.com/vim/vim/commit/6ac2e4aa0a565dc8cac73b33c9c099cea77212a8 Co-authored-by: Doug Kearns <dougkearns@gmail.com>
2025-05-02feat(build): build.zig MVP: build and run functionaltests on linuxbfredl1
NEW BUILD SYSTEM! This is a MVP implementation which supports building the "nvim" binary, including cross-compilation for some targets. As an example, you can build a aarch64-macos binary from an x86-64-linux-gnu host, or vice versa Add CI target for build.zig currently for functionaltests on linux x86_64 only Follow up items: - praxis for version and dependency bumping - windows 💀 - full integration of libintl and gettext (or a desicion not to) - update help and API metadata files - installation into a $PREFIX - more tests and linters
2024-11-14fix(tests): needing two calls to setup a screen is cringebfredl1
Before calling "attach" a screen object is just a dummy container for (row, col) values whose purpose is to be sent as part of the "attach" function call anyway. Just create the screen in an attached state directly. Keep the complete (row, col, options) config together. It is still completely valid to later detach and re-attach as needed, including to another session.
2024-11-08refactor(tests): continue the global highlight definition workbfredl1
2024-06-28refactor: use `vim._with` where possibledundargoc1
This mostly means replacing `nvim_buf_call` and `nvim_win_call` with `vim._with`.
2024-05-17feat(api): broadcast events to ALL channels #28487Justin M. Keyes1
Problem: `vim.rpcnotify(0)` and `rpcnotify(0)` are documented as follows: If {channel} is 0, the event is broadcast to all channels. But that's not actually true. Channels must call `nvim_subscribe` to receive "broadcast" events, so it's actually "multicast". - Assuming there is a use-case for "broadcast", the current model adds an extra step for broadcasting: all channels need to "subscribe". - The presence of `nvim_subscribe` is a source of confusion for users, because its name implies something more generally useful than what it does. Presumably the use-case of `nvim_subscribe` is to avoid "noise" on RPC channels not expected a broadcast notification, and potentially an error if the channel client reports an unknown event. Solution: - Deprecate `nvim_subscribe`/`nvim_unsubscribe`. - If applications want to multicast, they can keep their own multicast list. Or they can use `nvim_list_chans()` and `nvim_get_chan_info()` to enumerate and filter the clients they want to target. - Always send "broadcast" events to ALL channels. Don't require channels to "subscribe" to receive broadcasts. This matches the documented behavior of `rpcnotify()`.
2024-04-23test: improve test conventionsdundargoc1
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.
2024-04-10refactor(test): inject after_each differentlyLewis Russell1
2024-04-08test: improve test conventionsdundargoc1
Work on https://github.com/neovim/neovim/issues/27004.
2024-01-28vim-patch:9.1.0047: issues with temp curwin/buf while cmdwin is openSean Dewar1
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) Reset and save `cmdwin_old_curwin` in a similar fashion. Apply suitable changes for API functions and add Lua tests. https://github.com/vim/vim/commit/988f74311c26ea9917e84fbae608de226dba7e5f
2024-01-12test: rename (meths, funcs) -> (api, fn)Lewis Russell1
2024-01-12test: normalise nvim bridge functionsLewis Russell1
- remove helpers.cur*meths - remove helpers.nvim
2024-01-12test: typing for helpers.methsLewis Russell1
2024-01-03refactor: format test/*Justin M. Keyes1
2023-12-30test(functional): remove faulty pending checkChristian Clason1
Problem: `functional/vimscript/api_functions_spec` skips a test if the runtime files are not generated, but this check was broken in a refactor. Solution: Since runtime files are now generated for all test targets, do not skip this test.
2023-12-09test: avoid repeated screen lines in expected stateszeertzjq1
This is the command invoked repeatedly to make the changes: :%s/^\(.*\)|\%(\*\(\d\+\)\)\?$\n\1|\%(\*\(\d\+\)\)\?$/\=submatch(1)..'|*'..(max([str2nr(submatch(2)),1])+max([str2nr(submatch(3)),1]))/g
2023-07-26feat(api): allow win_hide to close cmdwin or non-previous windowsSean Dewar1
This aligns its behaviour better with `nvim_win_close`. Note that `:hide` is actually incapable of closing the cmdwin, unlike `:close` and `:quit`, so this is a bit of a difference in behaviour.
2023-07-05fix(api): disallow some more functions during textlockSean Dewar1
Problem: nvim_buf_set_text(), nvim_open_term() and termopen() all change buffer text, which is forbidden during textlock. Additionally, nvim_open_term() and termopen() may be used to convert the cmdwin buffer into a terminal buffer, which is weird. Solution: Allow nvim_buf_set_text() and nvim_open_term() in the cmdwin, but disallow nvim_open_term() from converting the cmdwin buffer into a terminal buffer. termopen() is not allowed in the cmdwin (as it always operates on curbuf), so just check text_locked(). Also happens to improve the error in #21055: nvim_buf_set_text() was callable during textlock, but happened to check textlock indirectly via u_save(); however, this caused the error to be overwritten by an unhelpful "Failed to save undo information" message when msg_list == NULL (e.g: an `<expr>` mapping invoked outside of do_cmdline()).
2023-07-05fix(api): use text_locked() to check textlockSean Dewar1
Problem: some API functions that check textlock (usually those that can change curwin or curbuf) can break the cmdwin. Solution: make FUNC_API_CHECK_TEXTLOCK call text_locked() instead, which already checks for textlock, cmdwin and `<expr>` status. Add FUNC_API_TEXTLOCK_ALLOW_CMDWIN to allow such functions to be usable in the cmdwin if they can work properly there; the opt-in nature of this attribute should hopefully help mitigate future bugs. Also fix a regression in #22634 that made functions checking textlock usable in `<expr>` mappings, and rename FUNC_API_CHECK_TEXTLOCK to FUNC_API_TEXTLOCK.
2023-05-30vim-patch:9.0.1588: Incsearch not triggered when pasting clipboard register ↵zeertzjq1
(#23817) Problem: Incsearch not triggered when pasting clipboard register on the command line. Solution: Also set "literally" when using a clipboard register. (Ken Takata, closes vim/vim#12460) https://github.com/vim/vim/commit/9cf6ab133227ac7e9169941752293bb7178d8e38 Co-authored-by: K.Takata <kentkt@csc.jp>
2023-05-21refactor(options): deprecate nvim[_buf|_win]_[gs]et_optionLewis Russell1
Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: famiu <famiuhaque@protonmail.com>
2023-04-04test: replace lfs with luv and vim.fsdundargoc1
test: replace lfs with luv luv already pretty much does everything lfs does, so this duplication of dependencies isn't needed.
2023-01-16refactor: remove E5500, adjust testszeertzjq1
Now with try_end() including more exception info, E5500 looks like redundant information. Adjust tests for more exception information.
2022-07-07vim-patch:8.2.0614: get ml_get error when deleting a line in 'completefunc' ↵zeertzjq1
(#19244) Problem: Get ml_get error when deleting a line in 'completefunc'. (Yegappan Lakshmanan) Solution: Lock the text while evaluating 'completefunc'. https://github.com/vim/vim/commit/ff06f283e3e4b3ec43012dd3b83f8454c98f6639 Fix a mistake in the porting of patch 8.1.0098. Cherry-pick Test_run_excmd_with_text_locked() from patch 8.2.0270. Cherry-pick test_gf.vim changes from patch 8.2.0369. Cherry-pick message change from later patches.
2021-09-17test: reorg #15698Justin M. Keyes1
Problem: Subdirectories like "visual", "insert", "normal" encourage people to separate *related* tests for no good reason. Typically the _mode_ is not the relevant topic of a test (and when it is, _then_ create an appropriate describe() or it()). Solution: - Delete the various `test/functional/<mode>/` subdirectories, move their tests to more meaningful topics. - Rename `…/normal/` to `…/editor/`. - Move or merge `…/visual/*` and `…/insert/*` tests into here where appropriate. - Rename `…/eval/` to `…/vimscript/`. - Move `…/viml/*` into here also. * test(reorg): insert/* => editor/mode_insert_spec.lua * test(reorg): cmdline/* => editor/mode_cmdline_spec.lua * test(reorg): eval core tests => eval_spec.lua