Problem:
decorations_spec.lua, float_spec.lua, multigrid_spec.lua are not
auto-formatted.
Solution:
Add a special `formatlua2` cmake target, which invokes `stylua` with
an alternative `.stylua2.toml` config.
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.
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
This is a breaking change which will make refactor of typval and shada
code a lot easier. In particular, code that would use or check for
v:msgpack_types.binary in the wild would be broken. This appears to be
rarely used in existing plugins.
Also some cases where v:msgpack_type.string would be used to represent a
binary string of "string" type, we use a BLOB instead, which is
vimscripts native type for binary blobs, and already was used for BIN
formats when necessary.
msgpackdump(msgpackparse(data)) no longer preserves the distinction
of BIN and STR strings. This is very common behavior for
language-specific msgpack bindings. Nvim uses msgpack as a tool to
serialize its data. Nvim is not a tool to bit-perfectly manipulate
arbitrary msgpack data out in the wild.
The changed tests should indicate how behavior changes in various edge
cases.
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.
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
`nvim_(get|set)_option_value` pick the current buffer / window by default for buffer-local/window-local (but not global-local) options. So specifying `buf = 0` or `win = 0` in opts is unnecessary for those options. This PR removes those to reduce code clutter.
Problem: Vim9: exception in ISN_INSTR caught at wrong level.
Solution: Set the starting trylevel in exec_instructions(). (closesvim/vim#8214)
ff65288aa8
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Confusing error for using a variable as a function.
Solution: If a function is not found but there is a variable, give a more
useful error. (issue vim/vim#9310)
2ef9156b42
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Does not include listener_*() functions.
js_*() functions are N/A.
json_encode() and json_decode() didn't include tests; add some anyway
(to json_functions_spec.lua).
test_lua.vim isn't included yet, so add tests to luaeval_spec.lua.
Strings that previously decoded into a msgpack special for representing
BINs with NULs now convert to Blobs. It shouldn't be possible to decode
into this special anymore after this change?
Notably, Lua strings with NULs now convert to Blobs when passed to VimL.
v:lua expressions are represented using vvlua_partial. As v:lua isn't
intended to be called directly, it's given an empty pt_name.
Because of this, calling v:lua directly like "v:lua()" will cause "E117:
Unknown function: ", with an empty name.
Instead, have call_func() show the name "v:lua" in the emsg.
- The previous commit lost information in the tests. Instead, add some
more "normalization" substitutions in pcall_err(), so that the general
shape of the stacktrace is included in the asserted text.
- Eliminate contains(), it is redundant with matches()
Can be reproduced with a script like this:
-- in some lua file
vim.fn.timer_start(10, function() error("uh....") end)
-- will cause neovim to crash with the following error.
PANIC: unprotected error in call to Lua API
(nlua_CFunction_func_call failed.)
After this, it will instead print the error message
from the top of the stack, like so.
tmp/error_nvim.lua:10: uh...
Also added an example test. Previously this test
caused the embedded nvim to panic.
vim-patch:8.2.1054: not so easy to pass a lua function to Vim
vim-patch:8.2.1084: Lua: registering function has useless code
I think I have also opened up the possibility for people to use these
callbacks elsewhere, since I've added a new struct that we should be
able to use.
Also, this should allow us to determine what the state of a list is in
Lua or a dictionary in Lua, since we now can track the luaref as we go.
- Return VimL errors instead of generic errors for:
- nvim_call_function
- nvim_call_dict_function
- Fix tests which were silently broken before this change.
This violates #6150 where we agreed not to translate API errors. But
that can be fixed later.
