| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
Result of `make iwyu` (after some "fixups").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
| |
listen_addr cannot be NULL at this point.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Now msgpack-c is never used for packing. The real fun part will be
replacing it for unpacking.
|
| |
|
|
| |
Step towords completely eliminating msgpack_packer.
|
| |
|
|
|
|
|
| |
Work towards getting rid of libmsgpack depedency eventually.
msgpack_sbuffer is just a string buffer, we can use our own
String type.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()`.
|
| | |
|
| |
|
|
| |
This will remove unrelated errors in .nvimlog at the end of test output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
Unpacker code now lives in unpacker.c
This was part of the old unpacker which I forgor to remove.
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Note: this contains two _temporary_ changes which can be reverted
once the Arena vs no-Arena distinction in API wrappers has been removed.
Both nlua_push_Object and object_to_vim_take_luaref() has been changed
to take the object argument as a pointer. This is not going to be
necessary once these are only used with arena (or not at all) allocated
Objects.
The object_to_vim() variant which leaves luaref untouched might need to
stay for a little longer.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and for return value of nlua_exec/nlua_call_ref, as this uses
the same family of functions.
NB: the handling of luaref:s is a bit of a mess.
add api_luarefs_free_XX functions as a stop-gap as refactoring
luarefs is a can of worms for another PR:s.
as a minor feature/bug-fix, nvim_buf_call and nvim_win_call now preserves
arbitrary return values.
|
| |
|
|
|
| |
In the context a String inside an Object/Dictionary etc is consumed,
it is considered to be read-only.
|
| |
|
|
|
|
|
|
|
| |
Problem:
rbuffer_consumed assertion fails if Unpacker fails to parse msgpack,
because it doesn't consume bytes on errors
Solution:
Call rbuffer_consumed_compact only if Unpacker isn't closed
|
| |
|
|
|
|
| |
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
|
| |
|
|
| |
Reference: https://github.com/neovim/neovim/issues/6371.
|
| | |
|
| |
|
| |
Discovered using __sanitizer_print_memory_profile().
|
| |
|
| |
A varargs functions can never be inlined, so a macro is faster.
|
| |
|
|
|
|
| |
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create mapping to most of the C spec and some POSIX specific functions.
This is more robust than relying files shipped with IWYU.
|
| |
|
|
|
|
| |
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
| |
|
|
|
| |
It is less error-prone than manually defining header guards. Pretty much
all compilers support it even if it's not part of the C standard.
|
| |
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
refactor: use a more idiomatic loop to iterate over the cells
There are two cases in which the following assertion would fail:
```c
assert(g->icell < g->ncells);
```
1. If `g->ncells = 0`. Update this to be legal.
2. If an EOF is reached while parsing `wrap`. In this case, the unpacker
attempts to resume from `cells`, which is a bug. Create a new state
for parsing `wrap`.
Reference: https://neovim.io/doc/user/ui.html#ui-event-grid_line
|
| |
|
|
|
| |
Uncrustify is the source of truth where possible.
Remove any redundant checks from clint.py.
|
