aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/api
Commit message (Collapse)AuthorAge
* Add API vim_replace_termcodesRui Abreu Ferreira2014-08-07
| | | | - Add API function to call replace_termcodes
* Refactor vim_feedkeys and f_feedkeysRui Abreu Ferreira2014-08-07
| | | | | | | | - 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
* Add helper cstr_as_string()Rui Abreu Ferreira2014-08-07
| | | | - Add nocopy helper alternative to cstr_to_string
* Return bool from find_win_for_buf #1023Wayne Rowcliffe2014-08-07
|
* api: make buffer_{get,set}_slice automatically assume `include_end`Thiago de Arruda2014-07-17
| | | | | This is for compatibility with python-vim interface: When passing an end index with a value higher than the last index, assume the `include_end` flag
* provider: New module used to expose extension points for core servicesThiago de Arruda2014-07-17
| | | | | | | | | | | | | | | | | 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.
* api: Refactor write_msg to use separate out/err buffersThiago de Arruda2014-07-17
|
* Use strict function prototypes #945Pavel Platto2014-07-14
| | | | | | | | | | | | | | | | | | | `-Wstrict-prototypes` warn if a function is declared or defined without specifying the argument types. This warning disallow function prototypes with empty parameter list. In C, a function declared with an empty parameter list accepts an arbitrary number of arguments when being called. This is for historic reasons; originally, C functions didn't have prototypes, as C evolved from B, a typeless language. When prototypes were added, the original typeless declarations were left in the language for backwards compatibility. Instead we should provide `void` in argument list to state that function doesn't have arguments. Also this warning disallow declaring type of the parameters after the parentheses because Neovim header generator produce no declarations for old-stlyle prototypes: it expects to find `{` after prototype.
* Remove stdbool.h from files which don't need itPavel Platto2014-07-11
| | | | | | | Done by manual inspection of the output of this script: grep -r -l -w "bool\|true\|false" * | grep 'c$\|h$' > has_bool grep -r -l "stdbool.h" * | grep 'c$\|h$' > has_include grep -F -x -v -f has_bool has_include
* Include stdbool.h in some files which use itPavel Platto2014-07-11
| | | | | | | Done by manual inspection of the output of this script: grep -r -l -w "bool\|true\|false" * | grep 'c$\|h$' > has_bool grep -r -l "stdbool.h" * | grep 'c$\|h$' > has_include grep -F -x -v -f has_include has_bool
* move errno.h include out of vim.hBrandon Coleman2014-07-09
|
* move assert.h include out of vim.hBrandon Coleman2014-07-09
|
* move ascii.h include out of vim.hBrandon Coleman2014-07-09
|
* Add vim_feedkeys API functionRui Abreu Ferreira2014-07-07
| | | | | | | | | | | - 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
* channel/msgpack_rpc: Refactor API dispatchingThiago de Arruda2014-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is how API dispatching worked before this commit: - The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer` argument. - The response is incrementally built while validating/calling the API. - Return values/errors are also packed into the `msgpack_packer` while the final response is being calculated. Now the `msgpack_packer` argument is no longer provided, and the `msgpack_rpc_dispatch` function returns `Object`/`Error` values to `msgpack_rpc_call`, which will use those values to build the response in a single pass. This was done because the new `channel_send_call` function created the possibility of having recursive API invocations, and this wasn't possible when sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly through the `msgpack_packer` instance). Since we only start to build the response when the necessary information has been computed, it's now safe to share a single `msgpack_sbuffer` instance across all channels and API invocations. Some other changes also had to be performed: - Handling of the metadata discover was moved to `msgpack_rpc_call` - Expose more types as subtypes of `Object`, this was required to forward the return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call` - Added more helper macros for casting API types to `Object` any
* channel: Implement the 'channel_send_call' functionThiago de Arruda2014-06-24
| | | | | | | | This function is used to send RPC calls to clients. In contrast to `channel_send_event`, this function will block until the client sends a response(But it will continue processing requests from that client). The RPC call stack has a maximum depth of 20.
* channel/msgpack_rpc: Refactor msgpack_rpc_notification/serialize_eventThiago de Arruda2014-06-24
| | | | | | | | | | - 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
* api: Add helper macros for dealing with API type castsThiago de Arruda2014-06-18
|
* api: Enable usage of Arrays and Dictionaries as [k]vectorsThiago de Arruda2014-06-18
| | | | | - Rename a/n/m to items/size/capactity in kvec.h - Add capactity field to Arrays/Dictionaries
* api: Rename find_{buffer,window,tabpage}Thiago de Arruda2014-06-18
| | | | | They were renamed to find_{buffer,window,tabpage}_by_handle to avoid conflicts with existing functions of the same name.
* Prevent null-pointer deference during vim_eval #785Andrew Chin2014-06-10
| | | | | If the eval_expr call in vim_eval returns NULL, a null-pointer deference would happen a few frames down, in vim_to_object_rec
* api: unify string conversions, simplify interopNicolas Hillegeer2014-06-08
| | | | | | | | | | | | | - The data member of String's can now be passed directly to functions expecting C strings, as we now guarantee that they are NUL-terminated. This obviates the need to use xstrndup and free, simplifying code and enhancing performance. - Use xmemdupz instead of xstrndup for converting String's into C strings. It's faster because it doesn't calculate strlen(string.data) (which is unnecesary as that information is already provided in string.size anyway). - Use cstr_to_string to convert from C strings to String, it is both shorter and faster than the usual strlen/xstrndup combo, which calls strlen twice. cstr_to_string internally calls strlen and then xmemdupz.
* api: also NUL-terminate Strings made from cstrsNicolas Hillegeer2014-06-08
| | | | | | I believe we can now mostly assume that all encountered String's data members are safe to pass into functions that accept C strings. That should simplify interop with C string code.
* api: remove some redundant string copiesNicolas Hillegeer2014-06-08
| | | | | Now that incoming Pascal strings are NULL-terminated by default, we can skip some spurious copies.
* text: remove useless arg from mb_string2cellsNicolas Hillegeer2014-06-08
| | | | | | | | | | | | | | | | | | 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: https://github.com/neovim/neovim/commit/677d30d7966dd2766bbf20665791c568dacc427a
* Add automatic generation of headersZyX2014-06-02
| | | | | | | | | | | | | | | | | - 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.
* Move documentation from function declarations to definitionsZyX2014-06-02
| | | | Uses a perl script to move it (scripts/movedocs.pl)
* Initialize Object, PositionJustin M. Keyes2014-05-31
| | | | | fix #778 thanks @genisaguilar
* Refactor: Redefine `Map(T)` as a more generic `Map(T, U)` macroThiago de Arruda2014-05-30
| | | | | To replace `Map(T)`, a new macro `PMap(T)` was defined as `Map(T, ptr_t)` for writing maps that store pointers with less boilerplate
* Extract cursor.h from misc{1,2}.h and memline.hHinidu2014-05-28
|
* API: Events: Add functions for {un}subscribing to broadcasted eventsThiago de Arruda2014-05-28
|
* API: Bugfix: Remove possible double-free in buffer_get_lineThiago de Arruda2014-05-28
|
* API: Bugfix: Remove memory leak from buffer_get_lineThiago de Arruda2014-05-26
|
* API: Bugfix: Remove memory leak from buffer_set_nameThiago de Arruda2014-05-26
|
* API: Bugfix: Remove memory leak from buffer_set_sliceThiago de Arruda2014-05-26
|
* API: Bugfix: Remove memory leak from set_option_toThiago de Arruda2014-05-26
|
* Build: Add more files to clint-files.txt and fix errorsThiago de Arruda2014-05-26
|
* API: Refactor: Duplicate/free string arguments coming from msgpackThiago de Arruda2014-05-26
| | | | | | | | | When receiving strings *from* msgpack, we don't need to duplicate/free since the data only lives in the msgpack parse buffer until the end of the call. But in order to reuse `msgpack_rpc_free_object` when sending event data(which is sent *to* msgpack), Strings must be freed, which means they must also be allocated separately.
* coverity: fix BUFFER_SIZE_WARNING with str{n,l}cpyNicolas Hillegeer2014-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relates to issue #760 These coverity warnings are of the form: >>> CID 62602: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes... This is caused by strncpy not alway NULL-terminated the destination buffer (for example in the case where strlen(src) >= size(dst)). It's better to replace that with (x)strlcpy, which always NULL-terminates. Most of these are related to the set_api_error macro, which uses strncpy. The error struct is used (for example) in msgpack_rpc_error, where strlen is executed on it, so it needs to be NULL-terminated. (x)strlcpy, unlike strncpy, always NULL-terminates the destination buffer. Relevant parts of the coverity report: *** CID 62602: Buffer not null terminated (BUFFER_SIZE_WARNING) /src/nvim/api/vim.c: 236 in vim_set_current_buffer() 230 if (try_end(err)) { 231 return; 232 } 233 234 char msg[256]; 235 snprintf(msg, sizeof(msg), "failed to switch to buffer %d", (int)buffer); >>> CID 62602: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "err->msg" of size 256 bytes might leave the >>> destination string unterminated. 236 set_api_error(msg, err); 237 return; 238 } 239 240 try_end(err); 241 } *** CID 62603: Buffer not null terminated (BUFFER_SIZE_WARNING) /src/nvim/api/private/helpers.c: 70 in try_end() 64 } else if (msg_list != NULL && *msg_list != NULL) { 65 int should_free; 66 char *msg = (char *)get_exception_string(*msg_list, 67 ET_ERROR, 68 NULL, 69 &should_free); >>> CID 62603: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "err->msg" of size 256 bytes might leave the >>> destination string unterminated. 70 strncpy(err->msg, msg, sizeof(err->msg)); 71 err->set = true; 72 free_global_msglist(); 73 74 if (should_free) { 75 free(msg); /src/nvim/api/private/helpers.c: 78 in try_end() 72 free_global_msglist(); 73 74 if (should_free) { 75 free(msg); 76 } 77 } else if (did_throw) { >>> CID 62603: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "err->msg" of size 256 bytes might leave the >>> destination string unterminated. 78 set_api_error((char *)current_exception->value, err); 79 } 80 81 return err->set; 82 } 83 *** CID 62604: Buffer not null terminated (BUFFER_SIZE_WARNING) /src/nvim/api/private/helpers.c: 592 in set_option_value_err() 586 opt_flags))) 587 { 588 if (try_end(err)) { 589 return; 590 } 591 >>> CID 62604: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "err->msg" of size 256 bytes might leave the >>> destination string unterminated. 592 set_api_error(errmsg, err); 593 } *** CID 62605: Buffer not null terminated (BUFFER_SIZE_WARNING) /src/nvim/os/server.c: 114 in server_start() 108 if (addr_len > sizeof(ip) - 1) { 109 // Maximum length of a ip address buffer is 15(eg: 255.255.255.255) 110 addr_len = sizeof(ip); 111 } 112 113 // Extract the address part >>> CID 62605: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on >>> destination array "ip" of size 16 bytes might leave the destination >>> string unterminated. 114 strncpy(ip, addr, addr_len); 115 116 int port = NEOVIM_DEFAULT_TCP_PORT; 117 118 if (*ip_end == ':') { 119 char *port_end; /src/nvim/os/server.c: 88 in server_start() 82 83 void server_start(char *endpoint, ChannelProtocol prot) 84 { 85 char addr[ADDRESS_MAX_SIZE]; 86 87 // Trim to `ADDRESS_MAX_SIZE` >>> CID 62605: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "addr" of size 256 bytes might leave the >>> destination string unterminated. 88 strncpy(addr, endpoint, sizeof(addr)); 89 90 // Check if the server already exists 91 if (map_has(cstr_t)(servers, addr)) { 92 EMSG2("Already listening on %s", addr); 93 return; *** CID 62606: Buffer not null terminated (BUFFER_SIZE_WARNING) /src/nvim/os/server.c: 186 in server_stop() 180 void server_stop(char *endpoint) 181 { 182 Server *server; 183 char addr[ADDRESS_MAX_SIZE]; 184 185 // Trim to `ADDRESS_MAX_SIZE` >>> CID 62606: Buffer not null terminated (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 256 bytes on >>> destination array "addr" of size 256 bytes might leave the >>> destination string unterminated. 187 188 if ((server = map_get(cstr_t)(servers, addr)) == NULL) { 189 EMSG2("Not listening on %s", addr); 190 return; 191 }
* API: Refactor: Fix buffer_get_markThiago de Arruda2014-05-23
|
* API: Refactor: Use macro for initializing all arraysThiago de Arruda2014-05-23
|
* API: Refactor: Implement buffer_get_numberThiago de Arruda2014-05-23
|
* API: Refactor: Return handles instead of indexesThiago de Arruda2014-05-23
| | | | | | | - 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.
* API: Refactor: Change the integer type of remote objects to uint64_tThiago de Arruda2014-05-23
|
* API: Refactor: Add macro infrastructure for typed arraysThiago de Arruda2014-05-23
| | | | | - Add macros supporting typed arrays in the remote API - Refactor StringArray-related functions on top of the new macros
* API: Refactor: Generalize buffer, window and tabpage types/functionsThiago de Arruda2014-05-23
| | | | | - Extract remote types definitions into a macro - Extract msgpack_rpc helper functions for remote types into a macro
* API: Refactor: Register/unregister created/destroyed tabpagesThiago de Arruda2014-05-23
| | | | | | | - Add the 'handle' field to `tabpage_T` - Add declare/implement functions for registering/unregistering/retrieving tabpages - Register/unregister tabpages when they are created/destroyed.
* API: Refactor: Register/unregister created/destroyed windowsThiago de Arruda2014-05-23
| | | | | | | - Add the 'handle' field to `win_T` - Add declare/implement functions for registering/unregistering/retrieving windows - Register/unregister windows when they are created/destroyed.
* API: Refactor: Register/unregister created/destroyed buffersThiago de Arruda2014-05-23
| | | | | | | - Add the 'handle' field to `buf_T` - Add declare/implement functions for registering/unregistering/retrieving buffers - Register/unregister buffers when they are created/destroyed.
* API: Refactor: Implement api/handle moduleThiago de Arruda2014-05-23
| | | | | This module will be used to implement remote management of objects through the API. Object types to be registered must have a `uint64_t` field named 'handle'.