| Commit message (Collapse) | Author | Age |
... | |
| | |
|
|/
|
|
|
|
|
| |
* Add api function get keymap
nvim_get_keymap(mode)
nvim_buf_get_keymap(buffer, mode)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Introduce multiqueue_process_priority() to process only events at or
above a certain priority.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| |
| |
| | |
- Work with a bool[] array parallel to the UIWidget enum.
- Rename some functions.
- Documentation.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Closes #5984
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | | |
throttle unneccessary cursor shape events
|
| |/ |
|
| | |
|
| |
| |
| |
| |
| | |
Should not really change anything, but code should be more efficient by using
more optimized libc functions (memchrsub is not libc, but it uses memchr) in
place of a cycle.
|
| | |
|
| | |
|
| | |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
Closes #6429
Closes #6430
|
| |
| |
| |
| | |
Closes #2583
|
| |
| |
| |
| |
| | |
- nvim_get_option should return the global default of a local option.
- nvim_set_option should set the global default of a local option.
|
| | |
|
| |
| |
| |
| | |
Also fixed an error in path_fnamecmp().
|
| | |
|
| | |
|
| |
| |
| |
| | |
Function was renamed and changed to return `const char *`.
|
| |
| |
| |
| | |
Also fixes buffer reusage in setmatches() and complete().
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Fixes problem introduced by “api: Allow kObjectTypeNil to be zero without
breaking compatibility”: apparently there are clients which use metadata and
there are which aren’t. For the first that commit would not be needed, for the
second that commit misses this critical piece.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|