When the buffer that nvim_buf_set_lines() is changing is not in any vim
window, fix_cursor() leads to calling ml_get_buf() with an invalid line
number. The condition that fix_cursor() was called on was (buf ==
curbuf), but this is always true because of the call to
switch_to_win_for_buf() earlier in the function.
Instead this should be predicated on (save_curbuf.br_buf == NULL)
It's important that users have a single, easy-to-remember place for
reading about the API. So this commit changes gen_api_vimdoc.py so that
the generated section is appended to api.txt instead of creating
a separate document.
Also remove the section numbering and ToC: it's a maintenance cost, and
it will be unnecessary when #5169 is integrated.
Reasonings:
1. It is not used for anything, but scope dictionaries currenly. So there is no
need to generalize and split it into dict_set_var (which will contain some
scope-dictionary-specific checks) and dict_set_value (which will work for any
dictionary).
2. Check for key size is no longer valid for non-scope dictionaries: you *can*
use empty keys there. In scope dictionaries also, but you actually are not
supposed to store there anything, but variables.
Note that actually one may still do
let b:[''] = 1
and “bypass” check for variable name. It won’t change what `echo b:` will show,
but it may affect code which iterates over scope dictionary keys and sets them
to something (if there is such code).
Problem: Using submatch() in a lambda passed to substitute() is verbose.
Solution: Use a static list and pass it as an optional argument to the
function. Fix memory leak.
df48fb456f
v7.4.2024 changed a few function signatures of functions that we use in
Neovim-specific code, e.g. the API.
Due to that the commit for 7.4.2024 doesn't build on its own, only together with
this commit.
Closes#731
References #851
Note: This does not remove some intentional legacy usages of strncpy.
- memcpy isn't equivalent because it doesn't check the string
length of `src`, and doesn't zero-out the remainder of `dst`.
- xstrlcpy isn't equivalent because it doesn't zero-out the
remainder of `dst`. Some Vim logic depends on that (e.g.
ex_append which calls vim_strnsave).
Helped-by: Douglas Schneider <ds3@ualberta.ca>
Helped-by: oni-link <knil.ino@gmail.com>
Helped-by: James McCoy <jamessan@jamessan.com>
Also fixed dumping of partials by encode_vim_to_object and added code which is
able to work with partials and dictionaries to test/unit/eval/helpers.lua
(mostly copied from #5119, except for partials handling).
This makes gdb backtraces much more meaningful: specifically I now know at which
line it crashes in place of seeing that it crashes at
TYPVAL_ENCODE_DEFINE_CONV_FUNCTIONS macros invocation.
Problem: Leaking memory when there is a cycle involving a job and a
partial.
Solution: Add a copyID to job and channel. Set references in items referred
by them. Go through all jobs and channels to find unreferenced
items. Also, decrement reference counts when garbage collecting.
107e1eef1d
vim-patch:7.4.1758
Problem: Triggering CursorHoldI when in CTRL-X mode causes problems.
Solution: Do not trigger CursorHoldI in CTRL-X mode. Add "!" flag to
feedkeys() (test with that didn't work though).
245c41070c
vim-patch:7.4.1759
Problem: When using feedkeys() in a timer the inserted characters are not
used right away.
Solution: Break the wait loop when characters have been added to typebuf.
use this for testing CursorHoldI.
40b1b5443c
vim-patch:7.4.1692
Problem: feedkeys('i', 'x') gets stuck, waits for a character to be typed.
Solution: Behave like ":normal". (Yasuhiro Matsumoto)
rv is int64_t but its address is being passed into win_get_tabwin as if
it were an int. This breaks on big-endian systems, since win_get_tabwin
will store the data to the "wrong" half of the int64_t, thus returning
invalid data out of nvim_win_get_number.
Since data.integer is a different (larger) integer type than
data.{buffer,window,tabpage}, we cannot abuse the union by using
data.integer to access the value for all 4 types. Instead, remove the
{buffer,window,tabpage} members and always use the integer member.
In order to accomodate this, perform distinct validation and coercion
between the Integer type and Buffer/Window/Tabpage types in
object_to_vim, msgpack_rpc helpers, and gendispatch.lua.
API level is disconnected from NVIM version. The API metadata holds the
current API level, and the lowest backwards-compatible level supported
by this instance.
Release 0.1.6 is the first release that reports the Nvim version and API
level.
metadata['version'] = {
major: 0,
minor: 1,
patch: 6,
api_level: 1,
api_compatible: 0,
api_prerelease: false,
}
The API level may remain unchanged across Nvim releases if the API has
not changed.
When changing the API,
- set NVIM_API_PRERELEASE to true
- increment NVIM_API_LEVEL (at most once per Nvim version)
- adjust NVIM_API_LEVEL_COMPAT if backwards-compatibility was broken
api_level_0.mpack was generated from Nvim 0.1.5 with:
nvim --api-info
The API level is disconnected from the NVIM version. The API metadata
holds the current API level, and the lowest backwards-compatible level
supported by this instance.
Release 0.1.6 will be the first release reporting the Nvim version and
API level.
metadata['version'] = {
major: 0,
minor: 1,
patch: 6,
prerelease: true,
api_level: 1,
api_compatible: 0,
}
The API level may remain unchanged across Neovim releases if the API has
not changed.
When changing the API the CMake variable NVIM_API_PRERELEASE is set to
true, and NVIM_API_CURRENT/NVIM_API_COMPATIBILITY are incremented
accordingly.
The functional tests check the API table against fixtures of past
versions of Neovim. It compares all the functions in the old table with
the new one, it does ignore some metadata attributes that do not alter
the function signature or were removed since 0.1.5. Currently the only
fixture is 0.mpack, generated from Neovim 0.1.5 with nvim --api-info.
