summaryrefslogtreecommitdiffstatshomepage
path: root/src/nvim/msgpack_rpc
AgeCommit message (Collapse)AuthorFiles
2026-04-08fix(rpc): trigger UILeave earlier on channel close (#38846)zeertzjq1
Problem: On exit, rpc_free() is called when processing main_loop.events after libuv calls close callbacks of the channel's stream. However, when there are no child processes, these libuv callbacks are called in loop_close() instead of proc_teardown(), and main_loop.events isn't processed after loop_close(). As a result, calling remote_ui_disconnect() in rpc_free() causes UILeave to depend on the presence of child processes. Solution: Always call remote_ui_disconnect() in rpc_close_event(), and remove the call in rpc_free().
2026-03-28fix(:restart): formalize restart event #35223Sathya Pramodh2
Problem: The "restart" event has some problems: - all UI clients must implement a somewhat complex set of setups - UI must be on the same machine as the server - only works for the "current" UI - race/edge case: If the user config has errors / waiting for input, are all UIs able to attach while Nvim is waiting for input? Solution: - Perform the restart on the server, not the client. - Pass listen address (instead of CLI args) in the UI event. - Simplifies UI logic: they only need to attach to new address. - Opens the door for more enhancements in the future, such as allowing all UIs to reattach instead of only the "current" UI. Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
2026-02-19fix(rpc): include write failure reason in log (#37959)zeertzjq1
Also don't use LOGLVL_ERR on UV_EPIPE.
2026-01-11fix(lua): vim._with() doesn't save boolean options properly (#37354)zeertzjq1
Problem: vim._with() doesn't save boolean options with false values properly. Solution: Use vim.F.if_nil().
2026-01-11fix(rpc): don't overwrite already received results on error (#37339)zeertzjq1
This fixes a regression from cf6f60ce4dc376570e8d71facea76299ca951604 (possibly), as before that commit a frame is popped from the call stack immediately after its response is received. Also fix leaking the allocated error messages.
2025-12-01fix(msgpack): use fixstr encoding for strings of length 20-31 #36737benarcher26911
Problem: MessagePack fixstr format supports string lengths 0-31, but mpack_str() only used fixstr for lengths < 20. Strings of 20-31 bytes were incorrectly encoded as str8 (2-byte header) instead of fixstr (1-byte header). Solution: Change the condition from `len < 20` to `len < 32` to match the MessagePack specification. This fix affects message timing which exposed a pre-existing race condition in the channels_spec PTY test. The test now uses a helper function to accumulate partial PTY reads, making it more robust. Fixes #32784
2025-10-24docs: types, news, lua-pluginJustin M. Keyes1
- mention "lua_ls", not "luals". https://github.com/neovim/neovim/discussions/36182 Co-authored-by: Maria Solano <majosolano99@gmail.com>
2025-10-09fix(rpc): handle more cases when identifying loopback #36100Vlad1
Problem: On MacOS it is a relatively common pattern to set XDG_RUNTIME_DIR under `/tmp` or `/var`. Both of these are symlinks to `/private/tmp` and `/private/var`. When checking for loopback the input address is normalized using `fix_fname`, however this is not applied to the addresses of the sockets. As a result of one address being normalized and the other not the comparison would fail. Solution: Normalize both sides of the comparison using `fix_fname`.
2025-10-04vim-patch:partial:8.1.1939: code for handling v: variables in generic eval ↵Jan Edmund Lazo1
file (#35968) Problem: Code for handling v: variables in generic eval file. Solution: Move v: variables to evalvars.c. (Yegappan Lakshmanan, closes vim/vim#4872) https://github.com/vim/vim/commit/e5cdf153bcb348c68011b308c8988cea42d6ddeb Remove direct reference to "vimvars" for following functions: - assert_error() - get_vim_var_nr() - get_vim_var_list() - get_vim_var_dict() - get_vim_var_str() - set_cmdarg() - set_reg_var() - set_vcount() - set_vexception() - set_vthrowpoint() - set_vim_var_bool() - set_vim_var_dict() - set_vim_var_list() - set_vim_var_nr() - set_vim_var_special() - set_vim_var_string() - set_vim_var_type() Reorder functions based on v8.2.4930 for eval_one_expr_in_str() and eval_all_expr_in_str(). Co-authored-by: Bram Moolenaar <Bram@vim.org>
2025-08-14refactor(build): remove INCLUDE_GENERATED_DECLARATIONS guardsbfredl8
These are not needed after #35129 but making uncrustify still play nice with them was a bit tricky. Unfortunately `uncrustify --update-config-with-doc` breaks strings with backslashes. This issue has been reported upstream, and in the meanwhile auto-update on every single run has been disabled.
2025-08-06refactor(build): don't use the preprocessor when generating headersbfredl2
Using the preprocessor before generating prototypes provides some "niceties" but the places that rely on these are pretty few. Vastly simplifying the BUILD SYSTEM is a better trade-off. Unbalancing { } blocks due to the preprocessor is cringe anyway (think of the tree-sitter trees!), write these in a different way. Add some workarounds for plattform specific features. INCLUDE_GENERATED_DECLARATIONS flag is now technically redundant, but will be cleaned up in a follow-up PR as it is a big mess.
2025-06-12fix(msgpack): flush incomplete big UI event before packing RPC eventbfredl2
This might happen, e.g. if we send a fast RPC reply in a os_breakcheck() in the middle of redrawing and big ui_ext events are produced. fixes #31316
2025-06-10fix(tui): wait for embedded server's exit codezeertzjq1
Uses the undocumented "error_exit" UI event for a different purpose: When :detach is used on the server, send an "error_exit" with 0 `status` to indicate that the server shouldn't wait for client exit.
2025-06-07feat: make :restart work for remote UI (#34354)zeertzjq1
2025-04-29fix(tui): don't process UI events when suspending or stopping (#33710)zeertzjq1
When the TUI is suspending or stopping, redraw events should not be processed, as when it next processes redraw events it's already waiting for a DA1 response after having disabled some terminal modes. Fix #33708
2025-04-16fix(env.c): drop envmap, free os_getenv() result #32683Judit Novak1
Problem: vim.uv.os_setenv gets "stuck" per-key. #32550 Caused by the internal `envmap` cache. #7920 :echo $FOO <-- prints nothing :lua vim.uv.os_setenv("FOO", "bar") :echo $FOO <-- prints bar (as expected) :lua vim.uv.os_setenv("FOO", "fizz") :echo $FOO <-- prints bar, still (not expected. Should be "fizz") :lua vim.uv.os_unsetenv("FOO") :echo $FOO <-- prints bar, still (not expected. Should be nothing) :lua vim.uv.os_setenv("FOO", "buzz") :echo $FOO <-- prints bar, still (not expected. Should be "buzz") Solution: - Remove the `envmap` cache. - Callers to `os_getenv` must free the result. - Update all call-sites. - Introduce `os_getenv_noalloc`. - Extend `os_env_exists()` the `nonempty` parameter.
2025-03-26docs: news, lsp autocomplete #33047Justin M. Keyes1
2025-03-24fix(channel): log after (not before) channel-closeJustin M. Keyes1
Problem: chan_close_on_err() writes to the log file before peforming its actual work. This could be slightly misleading in terms of log timestamps, or could delay important work on Windows where file-open/write can be slow. Solution: Log after closing the channel, instead of before.
2025-03-24refactor(channel): redundant channel_close()Justin M. Keyes1
Problem: `receive_msgpack()` calls `channel_close()` just before calling `chan_close_on_err()`, even though `chan_close_on_err()` always calls `channel_close()`. Solution: Remove the redunant `channel_close()` in `receive_msgpack()`.
2025-03-11fix(ui): schedule UI detach (#32827)Gregory Anders1
When a UI detaches it will execute any UILeave events. Autocommands cannot run in a libuv handler because they will in turn poll the event loop, which results in recursive loop execution. So we schedule the callback to detach the UI on the main event queue. We also have to schedule the exit when the RPC channel is closed to ensure it does not run until after `remote_ui_disconnect` has run, otherwise it will hang.
2025-02-17refactor(channel): eliminate special case in on_proc_exit() #32485Justin M. Keyes1
Problem: on_proc_exit() has a special-case that assumes that the UI client will never spawn more than 1 child process. Solution: If the Nvim server exits, the stream EOF will trigger `rpc_close()` in the UI client, so we don't need the special case in `on_proc_exit`. Pass `Channel.exit_status` from `rpc_close()` so that the correct exit code is reflected.
2025-02-10feat(ui): UI :detach commandJustin M. Keyes1
Problem: Cannot detach the current UI. Solution: - Introduce `:detach`. - Introduce `Channel.detach`. Co-authored-by: bfredl <bjorn.linse@gmail.com>
2025-02-05fix(log): RPC log format #32337Justin M. Keyes1
Problem: RPC log messages show `log_notify` function name, which is not useful: DBG 2025-02-04T22:28:02.419 ui.37862 log_notify:57: RPC -> 3: [notify] nvim_ui_set_focus DBG 2025-02-04T22:28:02.419 nvim.37863.0 log_notify:57: RPC <- 1: [notify] nvim_ui_set_focus Solution: Call logmsg() directly. DBG 2025-02-04T22:42:00.104 ui.40680 RPC: -> 3: [notify] nvim_ui_attach DBG 2025-02-04T22:42:00.104 ui.40680 RPC: -> 3: [notify] nvim_set_client_info
2024-12-23refactor: iwyu #31637Justin M. Keyes6
Result of `make iwyu` (after some "fixups").
2024-09-23refactor(api)!: rename Dictionary => DictJustin M. Keyes4
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.
2024-09-15refactor: rename "process" => "proc" #30387Justin M. Keyes1
Problem: - "process" is often used as a verb (`multiqueue_process_events`), which is ambiguous for cases where it's used as a topic. - The documented naming convention for processes is "proc". - `:help dev-name-common` - Shorter is better, when it doesn't harm readability or discoverability. Solution: Rename "process" => "proc" in all C symbols and module names.
2024-09-11feat(log): use "ui" as default name for TUI client #30345Justin M. Keyes1
The default "session name" for the builtin TUI is "ui". before: INF 2024-09-10T14:57:35.385 hello.sock os_exit:692: Nvim exit: 1 INF 2024-09-10T14:57:35.388 ?.4543 os_exit:692: Nvim exit: 1 after: INF 2024-09-10T14:59:19.919 hello.sock os_exit:692: Nvim exit: 1 INF 2024-09-10T14:59:19.922 ui.5684 os_exit:692: Nvim exit: 1
2024-09-10refactor(os/input.c): rename os_inchar => input_get #30327Justin M. Keyes1
Problem: The name `os_inchar` (from Vim's old `mch_inchar`) is ambiguous: "inchar" sounds like it could be reading or enqueuing (setting) input. Its docstring is also ambiguous. Solution: - Rename `os_inchar` to `input_get`. - Write some mf'ing docstrings. - Add assert() in TRY_READ().
2024-09-09fix(server): CID 509282: DEADCODE #30316Justin M. Keyes1
listen_addr cannot be NULL at this point.
2024-09-08fix(startup): server fails if $NVIM_APPNAME is relative dir #30310Justin M. Keyes1
Problem: If $NVIM_APPNAME is a relative dir path, Nvim fails to start its primary/default server, and `v:servername` is empty. Root cause is d34c64e342dfba9248d1055e702d02620a1b31a8, but this wasn't noticed until 96128a5076b7 started reporting the error more loudly. Solution: - `server_address_new`: replace slashes "/" in the appname before using it as a servername. - `vim_mktempdir`: always prefer the system-wide top-level "nvim.user/" directory. That isn't intended to be specific to NVIM_APPNAME; rather, each *subdirectory* ("nvim.user/xxx") is owned by each Nvim instance. Nvim "apps" can be identified by the server socket(s) stored in those per-Nvim subdirs. fix #30256
2024-09-08fix(startup): ignore broken $XDG_RUNTIME_DIR #30285Justin M. Keyes1
Problem: $XDG_RUNTIME_DIR may be broken on WSL, which prevents starting (and even building) Nvim. #30282 Solution: - When startup fails, mention the servername in the error message. - If an autogenerated server address fails, log an error and continue with an empty `v:servername`. It's only fatal if a user provides a bad `--listen` or `$NVIM_LISTEN_ADDRESS` address. Before: $ nvim --headless --listen ./hello.sock nvim: Failed to --listen: "address already in use" $ NVIM_LISTEN_ADDRESS='./hello.sock' ./build/bin/nvim --headless nvim: Failed to --listen: "address already in use" After: $ nvim --headless --listen ./hello.sock nvim: Failed to --listen: address already in use: "./hello.sock" $ NVIM_LISTEN_ADDRESS='./hello.sock' ./build/bin/nvim --headless nvim: Failed $NVIM_LISTEN_ADDRESS: address already in use: "./hello.sock"
2024-09-02feat(startup): validate --listen addressJustin M. Keyes1
Problem: `nvim --listen` does not error on EADDRINUSE. #30123 Solution: Now that `$NVIM_LISTEN_ADDRESS` is deprecated and input *only* (instead of the old, ambiguous situation where it was both an input *and* an output), we can be fail fast instead of trying to "recover". This reverts the "recovery" behavior of 704ba4151e7f67999510ee0ac19fdabb595d530c, but that was basically a workaround for the fragility of `$NVIM_LISTEN_ADDRESS`.
2024-08-05build(deps): remove msgpack-c dependencybfredl1
2024-08-05refactor(shada): rework msgpack decoding without msgpack-cbfredl4
This also makes shada reading slightly faster due to avoiding some copying and allocation. Use keysets to drive decoding of msgpack maps for shada entries.
2024-06-27refactor(shada): don't use msgpack_packer for shadabfredl1
Now msgpack-c is never used for packing. The real fun part will be replacing it for unpacking.
2024-06-24refactor(typval): don't use msgpack_packer for msgpackdump()bfredl1
Step towords completely eliminating msgpack_packer.
2024-06-11refactor(shada): use msgpack_sbuffer lessbfredl4
Work towards getting rid of libmsgpack depedency eventually. msgpack_sbuffer is just a string buffer, we can use our own String type.
2024-06-08refactor(io): make rstream use a linear bufferbfredl1
If you like it you shouldn't put a ring on it. This is what _every_ consumer of RStream used anyway, either by calling rbuffer_reset, or rbuffer_consumed_compact (same as rbuffer_reset without needing a scratch buffer), or by consuming everything in each stream_read_cb call directly.
2024-06-04fixup: include nvim/ascii_defs.hJames Tirta Halim1
2024-06-04fixup: apply the change on more filesJames Tirta Halim1
2024-05-31refactor(io): separate types for read and write streamsbfredl1
This is a structural refactor with no logical changes, yet. Done in preparation for simplifying rstream/rbuffer which will require more state inline in RStream. The initial idea was to have RStream and WStream as sub-types symetrically but that doesn't work, as sockets are both reading and writing. Also there is very little write-specific state to start with, so the benefit of a separate WStream struct is a lot smaller. Just document what fields in `Stream` are write specific.
2024-05-30refactor(fileio): use a linear buffer for FileDescriptorbfredl1
Using a ring buffer for buffered synchronous fileio is just unnecessary complexity. - when reading, we always consume the _entire_ buffer before getting into syscalls. Thus we reset the buffer to its initial position before when we actually read. - when writing and buffer is full, we always flush the entire buffer before starting to buffer again. So we can reset the buffer to its initial state. Also no static buffers are needed for writing and skipping. Needing an extra copy for each write completely defeated the purpose of a ring buffer (if there had been one)
2024-05-17feat(api): broadcast events to ALL channels #28487Justin M. Keyes2
Problem: `vim.rpcnotify(0)` and `rpcnotify(0)` are documented as follows: If {channel} is 0, the event is broadcast to all channels. But that's not actually true. Channels must call `nvim_subscribe` to receive "broadcast" events, so it's actually "multicast". - Assuming there is a use-case for "broadcast", the current model adds an extra step for broadcasting: all channels need to "subscribe". - The presence of `nvim_subscribe` is a source of confusion for users, because its name implies something more generally useful than what it does. Presumably the use-case of `nvim_subscribe` is to avoid "noise" on RPC channels not expected a broadcast notification, and potentially an error if the channel client reports an unknown event. Solution: - Deprecate `nvim_subscribe`/`nvim_unsubscribe`. - If applications want to multicast, they can keep their own multicast list. Or they can use `nvim_list_chans()` and `nvim_get_chan_info()` to enumerate and filter the clients they want to target. - Always send "broadcast" events to ALL channels. Don't require channels to "subscribe" to receive broadcasts. This matches the documented behavior of `rpcnotify()`.
2024-04-16fix(msgpack): store grid line event as a valueTheo Fabi3
2024-04-02test: silence expected errorsdundargoc1
This will remove unrelated errors in .nvimlog at the end of test output.
2024-03-07refactor(msgpack): allow flushing buffer while packing msgpackbfredl7
Before, we needed to always pack an entire msgpack_rpc Object to a continous memory buffer before sending it out to a channel. But this is generally wasteful. it is better to just flush whatever is in the buffer and then continue packing to a new buffer. This is also done for the UI event packer where there are some extra logic to "finish" of an existing batch of nevents/ncalls. This doesn't really stop us from flushing the buffer, just that we need to update the state machine accordingly so the next call to prepare_call() always will start with a new event (even though the buffer might contain overflow data from a large event).
2024-02-26refactor(msgpack): remove dead unpacker code in helpersbfredl1
Unpacker code now lives in unpacker.c This was part of the old unpacker which I forgor to remove.
2024-02-21refactor(api): make freeing of return-value opt-in instead of opt outbfredl1
As only a few API functions make use of explicit freeing of the return value, make it opt-in instead. The arena is always present under the hood, so `Arena *arena` arg now doesn't mean anything other than getting access to this arena. Also it is in principle possible to return an allocated value while still using the arena as scratch space for other stuff (unlikely, but there no reason to not allow it).
2024-02-18refactor(api): use arena for metadata; msgpack_rpc_to_object delenda estbfredl2
Note: kSDItemHeader is something is _written_ by nvim in the shada file to identify it for debugging purposes outside of nvim. But this data wasn't ever used by neovim after reading the file back, So I removed the parsing of it for now.
2024-02-18refactor(api): use arena for channel info and terminal infobfredl1