Rationale: the purpose of nvim_execute_lua is to simply call lua code with lua
values. If a lua function expects a floating point value, it should be enough
to specify a float as argument to nvim_execute_lua.
However, make sure to preserve the existing roundtripping behavior of
API values when using `vim.api` functions. This is covered by existing
lua/api_spec.lua tests.
The test.functional.helpers and test.unit.helpers modules now include
all of the public functions from test.helpers, so there is no need to
separately require('test.helpers').
Before now, Nvim always degrades UI capabilities to the lowest-common
denominator. For example, if any connected UI has `ext_messages=false`
then `ext_messages=true` requested by any other connected UI is ignored.
Now `nvim_ui_attach()` supports `override=true`, which flips the
behavior: if any UI requests an `ext_*` UI capability then the
capability is enabled (and the legacy behavior is disabled).
Legacy UIs will be broken while a `override=true` UI is connected, but
it's useful for debugging: you can type into the TUI and observe the UI
events from another connected (UI) client. And the legacy UI will
"recover" after the `override=true` UI disconnects.
Example using pynvim:
>>> n.ui_attach(2048, 2048, rgb=True, override=True, ext_multigrid=True, ext_messages=True, ext_popupmenu=True)
>>> while True: n.next_message();
CA_COMMAND_BUSY in nv_event() was carried over from Vim nv_cursorhold()
(ref: e5165bae11). It prevents :startinsert from working during a RPC
call, so remove it.
Helped-by: glacambre <me@r4>
closes#7254
Loading existing files into a buffer is non-trivial and requires a window.
Creating an unnamed emtpy buffer is trivial and safe though, thus worth a
special case.
Change nvim_buf_set_option to use aucmd_prepbuf. This is necessary
to allow some options to be set on a not yet displayed buffer, such
as 'buftype' option.
vim-patch:7.4.1858: Add BLN_NEW to enforce buflist_new creating new buffer
Namespaces is a lightweight concept that should be used to group
objects for purposes of bulk operations and introspection. This is
initially used for highlights and virtual text in buffers, and is
planned to also be used for extended marks. There is no plan use them
for privileges or isolation, neither to introduce nanespace-level
options.
msgpack_rpc_to_object (called by handle_request .. msgpack_rpc_to_array)
always NUL-terminates API Strings.
But handle_request .. msgpack_rpc_get_handler_for operates on a raw
msgpack_object, before preparation.
Add ext_newgrid and ext_hlstate extensions. These use predefined
highlights and line-segment based updates, for efficiency and
simplicity.. The ext_hlstate extension in addition allows semantic
identification of builtin and syntax highlights.
Reimplement the old char-based updates in the remote UI layer, for
compatibility. For the moment, this is still the default. The bulitin
TUI uses the new line-based protocol.
cmdline uses curwin cursor position when ext_cmdline is active.
- 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.
The `internal` param is difficult to explain, and will rarely be
anything but `true`. To avoid it, use a hack: check if the resolved
dict value starts with "function(".
Make `:verbose set ...` show when an option was last modified by an
API client or Lua script/chunk. In the case of an API client, the
channel ID is displayed.
Implement nvim_command_output with `execute({cmd},"silent")`.
Behavior changes:
- does not provoke any hit-enter prompt
- no longer prepends a newline char
- does not capture some noise (like the "[New File]" message, see the
change to tabnewentered_spec.lua)
Technically ("bug-for-bug") this a breaking change. But the previous
behavior of nvim_command_output meant that it probably wasn't used for
anything outside of tests.
Also remove the undocumented `v:command_output` variable which was
a hack introduced only for the purposes of nvim_command_output.
closes#7726
The "mapping" tests added in 541dde36e3 were flawed:
- Unlike op-pending mode, RPCs are _blocked_ during map-pending. So
a synchronous RPC like nvim_get_current_buf() waits until
'timeoutlen', then the mapping is canceled.
- helpers.expect() also performs a blocking RPC, so again that must not
intervene the two nvim_input() calls.
closes#6166
normal_finish_command() and normal_prepare() assume that any pending
operator needs to be finished after any subsequent key.
Set `finish_op = false` in nv_event() to indicate that the pending
operator shouldn't be finished in normal_execute().
This is how nv_visual() indicates that 'v' or 'V' in operator-pending
mode should not finish the current pending operator.
fixes#5398fixes#6166 (partially; mappings are still interrupted)
Asynchronous API functions are served immediately, which means pending
input could change the state of Nvim shortly after an async API function
result is returned.
nvim_get_mode() is different:
- If RPCs are known to be blocked, it responds immediately (without
flushing the input/event queue)
- else it is handled just-in-time before waiting for input, after
pending input was processed. This makes the result more reliable
(but not perfect).
Internally this is handled as a special case, but _semantically_ nothing
has changed: API users never know when input flushes, so this internal
special-case doesn't violate that. As far as API users are concerned,
nvim_get_mode() is just another asynchronous API function.
In all cases nvim_get_mode() never blocks for more than the time it
takes to flush the input/event queue (~µs).
Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if
e.g. `d` is operator-pending.
Closes#6159
Also re-word some error messages:
- "Key does not exist: %s"
- "Invalid channel: %<PRIu64>"
- "Request array size must be 4 (request) or 3 (notification)"
- "String cannot contain newlines"
References #6150
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.
In Windows Lua's os.tmpname() returns relative paths starting with \s,
prepend them with $TEMP to generate a valid path.
In OS X os.tmpname() returns paths in '/tmp' but they should be in
'/private/tmp'. We cannot use os_name() for platform detection because
some tests use tempname() before nvim is spawned, instead use one of the
following:
1. Set SYSTEM_NAME environment variable before calling the tests, it
is set from CMAKE_SYSTEM_NAME(i.e. uname -s or 'Windows')
2. Call uname -s
3. Assume windows
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
Adds support for:
- api:vim_input("<D-a>")
- ":nnoremap <C-D-S-...>" and permutations thereof
UIs must capture the modifier and send it as "<D-...>" to vim_input().
Note: Before this commit, any arbitrary ":nnoremap <{foo}-{bar}>"
mapping could already be invoked with feedkeys("\<{foo}-{bar}>"). This
commit supports "D-" as a modifier that can be combined with "C-", "A-",
"S-" in any order.
For non-GUI (terminal) support, user must:
:set <D-a>={CSI sequence}
then send the {CSI sequence} from their terminal. But this does not work
yet (regression #2204).
Closes#2190
Refactor input.c, normal.c and edit.c to use the K_EVENT special key to trigger
the CURSORHOLD event. In normal and edit mode, K_EVENT is treated as
K_CURSORHOLD, which enables better handling of arbitrary actions in those
states(eg: In normal mode the previous operator counts will be restored).
Also fix a test in vim_spec.lua. The test had a wrong assumption: cmdheight is
only used to determine when the press enter screen will be shown, not to limit
how many lines or control pagination.
Sanity API checks made by the python-client in the api-python travis target were
converted to lua and will now live in this repository. This will simplify
performing breaking changes to the API as it won't be necessary to send parallel
PRs the python-client.
