| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
continues d0af4cd9094f.
This commit renames positional parameters. This is only "cosmetic", but
is intended to make it extra clear which name is preferred, since people
often copy existing code despite the guidelines in `:help dev-naming`.
|
|
|
|
"Error" in error messages is redundant. Just provide the context, don't
say "Error ...".
|
|
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.
|
|
Problem:
Tests have lots of exec_lua calls which input blocks of code
provided as unformatted strings.
Solution:
Teach exec_lua how to handle functions.
|
|
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.
|
|
|
|
Work on https://github.com/neovim/neovim/issues/27004.
|
|
|
|
|
|
|
|
When we convert a Lua table to an Object, we consider the table a
"dictionary" if it contains only string keys, and an array if it
contains all numeric indices with no gaps. While rare, Lua tables can
have both strictly numeric indices and gaps (e.g. { [2] = 2 }). These
currently cannot be serialized because it is not considered an array.
However, we know the maximum index of the table and as long as all of
the keys in the table are numeric, it is still possible to serialize
this table as an array. The missing indices will have nil values.
|
|
Currently (as of nvim 0.9), the behavior of boolean params in
vim.api lua wrappers is inconsistent for optional parameters
(part of an `opts` dict) compared to positional parameters.
This was inadvertently changed in #24524 . While cleaning up this
inconsistency is something we might want eventually, it needs
to be discussed separately and the impact of existing code considered.
|
|
|
|
Problem: Vim9: exception in ISN_INSTR caught at wrong level.
Solution: Set the starting trylevel in exec_instructions(). (closes vim/vim#8214)
https://github.com/vim/vim/commit/ff65288aa89dcd50760ad942d58baff70c6e93e6
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
- VALIDATE() takes a format string
- deduplicate check_string_array
- VALIDATE_RANGE
- validate UI args
|
|
Co-authored-by: Raphael <glephunter@gmail.com>
Co-authored-by: smjonas <jonas.strittmatter@gmx.de>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
Looks like I did an oopsie; although API strings carry a size field, they should
still be usable as C-strings! (even though they may contain embedded NULs)
|
|
Solves #13651
Co-authored-by: Gregory Anders <greg@gpanders.com>
|
|
Add support for adding and removing custom user commands with the Nvim
API.
|
|
|
|
|
|
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.
|
|
Note that these are not NUL-terminated; the API supports this.
|
|
|
|
Also simplify error messages when calling lua from vimL.
|
|
|
|
|
|
|
|
Reasoning is majorly the same: check whether lua has bug or API function has
bug, but on the other side: previous commit is checking whether similar bug when
using API via msgpack RPC, this commit is checking whether another API function
used via lua bindings triggers the same bug. Should additionally give a hint
about which lua code contains a bug.
|
|
|
|
|
|
|
|
|
|
|
