| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()`.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Added to support MessagePack-RPC fully compliant clients that do
not return responses in request order.
Although it is currently not an efficient implementation for full
compliance and full compliance cannot be guaranteed, the addition
of the new client type `msgpack-rpc` creates a situation where "if
the client type is `msgpack-rpc`, then backward compatibility is
ignored and full compliance with MessagePack- RPC compliance is
justified even if backward compatibility is ignored if the client
type is `msgpack-rpc`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the total number of khash_t instantiations from 22 to 8.
Make the khash internal functions take the size of values as a runtime
parameter. This is abstracted with typesafe Map containers which
are still specialized for both key, value type.
Introduce `Set(key)` type for when there is no value.
Refactor shada.c to use Map/Set instead of khash directly.
This requires `map_ref` operation to be more flexible.
Return pointers to both key and value, plus an indicator for new_item.
As a bonus, `map_key` is now redundant.
Instead of Map(cstr_t, FileMarks), use a pointer map as the FileMarks struct is
humongous.
Make `event_strings` actually work like an intern pool instead of wtf it
was doing before.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
drawback: tracing memory errors with ASAN is less accurate for arena
allocated memory.
Therefore, to start with it is being used for Object types around
serialization/deserialization exclusively. This is going to have
a large impact especially when TUI is refactored as a co-prosess
as all UI events will be serialized and deserialized by nvim itself.
|
| |
|
|
|
|
|
|
|
|
| |
Currently this is more or less a straight off reimplementation,
but this allow further optimizations down the line, especially
for avoiding memory allocations of rpc objects.
Current score for "make functionaltest; make oldtest" on a -DEXITFREE build:
is 117 055 352 xfree(ptr != NULL) calls (that's NUMBERWANG!).
|
| |
|
|
|
| |
This avoids generating khash tables at runtime, and is consistent with
how evalfuncs lookup work.
|
| |
|
|
|
|
| |
* refactor: format header files with uncrustify
* fixup(justin): skip formatting of terminfo_defs.h
* fixup: force winsock2 to be included first
* fixup: simplify disable/enable directive to "uncrustify:off/on"
|
| |
|
|
|
|
|
|
|
|
| |
Note: the reason for removing them is not that there after this refactor
is no use of them, but rather that having them available is an
anti-pattern: they manange an _extra_ heap allocation which has
nothing to do with the functionality of the map itself (khash
manages the real buffers internally). In case there happens to
be a reason to allocate the map structure itself later, this
should be made explicit using xcalloc/xfree calls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to [MessagePack RPC specification](https://github.com/msgpack-rpc/msgpack-rpc),
message ID must be 32-bit unsigned integer. But Neovim implementation
uses uint64_t instead of uint32_t. This can have wrong results in the
case of large ids or a malformed request, for example:
Actual response: [1,18446744073709551615,[1,"Message is not an array"],null]
Expected response: [1,4294967295,[1,"Message is not an array"],null]
The issue does not affect RPC clients written in dynamically-typed
languages like Python. Wrong type of sequence id number breaks RPC
clients written statically typed languages like C/C++/Golang: all of
them expect uint32_t as message id.
Examples:
https://github.com/msgpack-rpc/msgpack-rpc-cpp/blob/11268ba2be5954ddbb2b7676c7da576985e45cfc/src/msgpack/rpc/protocol.h#L27
https://github.com/ugorji/go/blob/master/codec/msgpack.go#L993
closes #8850
|
| |
|
|
|
|
|
|
|
|
| |
Using a sentinel value in the response-id is ambiguous because the
msgpack-rpc spec allows all values (including zero/max). And clients
control the id, so we can't be sure they won't use the sentinel value.
Instead of a sentinel value, check the message type explicitly.
ref #8850
|
| |
|
|
|
| |
Fire autocmd when channel opens or its info changes.
Add a way for API clients can describe themselves.
|
| |
|
