Specialized array types(BufferArray, WindowArray, etc) were added to the API for
two main reasons:
- msgpack used to lack a way of serializing appliaction-specific types and there
was no obvious way of making an API function accept/return arrays of custom
objects such as buffers(which are represented as integers, so clients didn't
have a way to distinguish from normal numbers)
- Let clients in statically-typed languages that support generics have a better
typed API
With msgpack 2.0 EXT type the first item is no longer a factor and this commit
starts by removing the specialized array types. The second item will be
addressed in the future by making the API metadata return extra useful
information for statically-typed languages.
- To clean up the mix between feedkeys and replace_termcodes
the vim_feedkeys API function now does the same thing as the
vimscript feedkeys() function
- The original f_feedkeys() function now calls the vim_feedkeys()
function from the API
Introducing the concept of providers: co-processes that talk with the editor
through the remote API and provide implementation for one or more core
services.
The `provider_register` function and it's API wrapper can be used by channels
that want to self-register as a service provider.
Some old builtin vim features will be re-implemented as providers. The
`provider_has_feature` function is used to check if a provider
implementing a certain feature is available(It will be called by the `has`
vimscript function to check for features in a vim-compatible way)
This implements the provider module without exposing any extension points, which
will be done in future commits.
- New API function to push data to the typeahead buffer - this should
equivalent to the vimscript feedkeys() function
- In Vim there was a --remote-send command to insert input into a
Vim server instance. Besides accepting key sequences it also
translated special keys such as <CR> or <Leader>, backslash notation
is ignored. This commit backports the original Vim handler for
--remote-send as a bool option for vim_feedkeys()
- vim-patch:0
- Generalize some argument names(event type -> event name,
event data -> event arg)
- Rename serialize_event to serialize_message
- Rename msgpack_rpc_notification to msgpack_rpc_message
- Extract the message type out of msgpack_rpc_message
- Add 'id' parameter to msgpack_rpc_message/serialize_message to create messages
that are not notifications
mb_string2cells was always called like mb_string2cells(..., -1) so that was
the only codepath that was tested. @tarruda was the first to try to input an
actual length, after which valgrind detected that funny business was going
on.
It's not even possible to do the right thing with the current text codec
infrastructure: they all assume to be working with C strings. Meaning that
if there is no NUL-terminator, they will happily keep on reading past the
end of Pascal strings. Ergo, passing the length parameter is moot. The
condition in the for-loop was wrong as well (but that's no longer relevant).
Also change the return value to size_t, by analogy with strlen.
ref:
677d30d796
- The 'stripdecls.py' script replaces declarations in all headers by includes to
generated headers.
`ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'`
was used for this.
- Add and integrate gendeclarations.lua into the build system to generate the
required includes.
- Add -Wno-unused-function
- Made a bunch of old-style definitions ANSI
This adds a requirement: all type and structure definitions must be present
before INCLUDE_GENERATED_DECLARATIONS-protected include.
Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is
the only exception.
- Define specialized arrays for each remote object type
- Implement msgpack_rpc functions for dealing with the new types
- Refactor all functions dealing with buffers, windows and tabpages to
return/accept handles instead of list indexes.
While the mb_string2cells function accepts a length parameter, it only seems to
work properly with 0-terminated strings, since valgrind reports a conditional
jump that depends on uninitialized values(means it reads after the string
boundaries which could result in overflows or wrong results)
Instead of exposing native C types to a public API that can be consumed by other
platforms, we are now using the following translation:
int64_t -> Integer
double -> Float
bool -> Boolean
Problem: Some newly introduced files used includes relative to the
current file, both of the form `include "../XXX.h"` and
`include "XXX.h"`.
Preferred form is relative to include root (src/ in our case).
Solution: Change includes to preferred form.
Note: This is also done to ease next commit (prepend 'nvim/ to all
project-local includes).
Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
