Function declarations generator is able to handle properly only the *first*
function definition that is in macros, and only if it is the first entity in the
macros. So msgpack_rpc_from_* was already really a static function, additionally
its attributes were useless. This commit switches to explicit declarations and
makes generated functions static.
Reasoning; currently INTERNAL_CALL is mostly used to determine whether it is
needed to deal with NL-used-as-NUL problem. This code is useful for nvim_… API
calls done from VimL, but not for API calls done from lua, yet lua needs to
supply something as channel_id.
During testing found the following bugs:
1. msgpack-gen.lua script is completely unprepared for Float values either in
return type or in arguments. Specifically:
1. At the time of writing relevant code FLOAT_OBJ did not exist as well as
FLOATING_OBJ, but it would be used by msgpack-gen.lua should return type
be Float. I added FLOATING_OBJ macros later because did not know that
msgpack-gen.lua uses these _OBJ macros, otherwise it would be FLOAT_OBJ.
2. msgpack-gen.lua should use .data.floating in place of .data.float. But it
did not expect that .data subattribute may have name different from
lowercased type name.
2. vim_replace_termcodes returned its argument as-is if it receives an empty
string (as well as _vim_id*() functions did). But if something in returned
argument lives in an allocated memory such action will cause double free:
once when freeing arguments, then when freeing return value. It did not cause
problems yet because msgpack bindings return empty string as {NULL, 0} and
nothing was actually allocated.
3. New code in msgpack-gen.lua popped arguments in reversed order, making lua
bindings’ signatures be different from API ones.
No tests yet, no documentation update, no :lua* stuff, no vim module.
converter.c should also work with typval_T, not Object.
Known problem: luaeval("1", {}) results in
PANIC: unprotected error in call to Lua API (attempt to index a nil value)
Ref #3823
The comment is incorrect, s:error does need to be called. I thought the
call was unnecessary because it didn't show any message for me but I had
shortmess+=F which was hiding the message.
Problem: When virtcol() gets a column that is not the first byte of a
multi-byte character the result is unpredictable. (Christian
Ludwig)
Solution: Correct the column to the first byte of a multi-byte character.
Change the utf-8 test to new style.
0c0590d982Closes#6269
During free_all_mem, somehow ex_tabonly() may free aucmd_win. But it
isn't fully destroyed (maybe autocmd_busy?). When win_free_all() tries
to free aucmd_win directly, it double-frees the sub-fields.
Tried unnsuccessfully to work around this by invoking `:tabonly!` with
autocmds disabled:
diff --git a/src/nvim/memory.c b/src/nvim/memory.c
index 58c01fbe7a12..91c845e94d22 100644
--- a/src/nvim/memory.c
+++ b/src/nvim/memory.c
@@ -565,9 +565,9 @@ void free_all_mem(void)
/* Close all tabs and windows. Reset 'equalalways' to avoid redraws. */
p_ea = false;
if (first_tabpage->tp_next != NULL)
- do_cmdline_cmd("tabonly!");
+ do_cmdline_cmd("noautocmd tabonly!");
if (firstwin != lastwin)
- do_cmdline_cmd("only!");
+ do_cmdline_cmd("noautocmd only!");
/* Free all spell info. */
spell_free_all();
In order to re-order marks according to the :move command, do_move()
uses mark_adjust() in a non-standard manner. The non-standard action is
that it moves some marks *past* other marks. This doesn't matter for
marks, but mark_adjust() calls foldMarkAdjust() which simply changes
fold starts and lengths and doesn't have enough information to know that
other folds have to be checked and reordered.
The array of folds for each window are assumed to be in order of
increasing line number, and if this gets broken some folds can get
"lost".
There has been a previous patch to avoid this problem by deleting and
recalculating all folds in the window, but this comes at the cost of
closing all folds when executing :move, and doesn't cover the case of
manual folds.
This patch adds a new function foldMoveRange() specifically for the
:move command that handles reordering folds as well as simply moving
them. Additionally, we allow calling mark_adjust_nofold() that does the
same as mark_adjust() but doesn't affect any fold array.
Calling mark_adjust_nofold() should be done in the same manner as
calling mark_adjust(), but according changes to the fold arrays must be
done seperately by the calling function.
vim-patch:8.0.0457
vim-patch:8.0.0459
vim-patch:8.0.0461
vim-patch:8.0.0465
Problem: Asan detects a memory error when EXITFREE is defined. (Dominique
Pelle)
Solution: In getvcol() check for ml_get_buf() returning an empty string.
Also skip adjusting the scroll position. Set "exiting" in
mch_exit() for all systems.
955f198fc5
