diff options
Diffstat (limited to 'runtime/doc/api.txt')
| -rw-r--r-- | runtime/doc/api.txt | 27 |
1 files changed, 13 insertions, 14 deletions
diff --git a/runtime/doc/api.txt b/runtime/doc/api.txt index c260101e92..9fabc1cf8b 100644 --- a/runtime/doc/api.txt +++ b/runtime/doc/api.txt @@ -85,7 +85,7 @@ Buffer update events *api-buffer-updates* API clients can "attach" to Nvim buffers to subscribe to buffer update events. This is similar to |TextChanged| but more powerful and granular. -Call |nvim_buf_attach| to receive these events on the channel: +Call |nvim_buf_attach()| to receive these events on the channel: *nvim_buf_lines_event* nvim_buf_lines_event[{buf}, {changedtick}, {firstline}, {lastline}, {linedata}, {more}] @@ -150,7 +150,7 @@ nvim_buf_detach_event[{buf}] *nvim_buf_detach_event* EXAMPLE ~ -Calling |nvim_buf_attach| with send_buffer=true on an empty buffer, emits: > +Calling |nvim_buf_attach()| with send_buffer=true on an empty buffer, emits: > nvim_buf_lines_event[{buf}, {changedtick}, 0, 0, [""], v:false] User adds two lines to the buffer, emits: > @@ -189,12 +189,11 @@ Another use case are plugins that show output in an append-only buffer, and want to add highlights to the outputs. Highlight data cannot be preserved on writing and loading a buffer to file, nor in undo/redo cycles. -Highlights are registered using the |nvim_buf_add_highlight| function, see the -generated API documentation for details. If an external highlighter plugin is -adding a large number of highlights in a batch, performance can be improved by -calling |nvim_buf_add_highlight| as an asynchronous notification, after first -(synchronously) reqesting a source id. Here is an example using wrapper -functions in the python client: +Highlights are registered using the |nvim_buf_add_highlight()| function. If an +external highlighter plugin wants to add many highlights in a batch, +performance can be improved by calling |nvim_buf_add_highlight()| as an +asynchronous notification, after first (synchronously) reqesting a source id. +Example using the Nvim python-client: > src = vim.new_highlight_source() @@ -207,10 +206,10 @@ functions in the python client: buf.clear_highlight(src) < If the highlights don't need to be deleted or updated, just pass -1 as -src_id (this is the default in python). |nvim_buf_clear_highlight| can be used -to clear highlights from a specific source, in a specific line range or the -entire buffer by passing in the line range 0, -1 (the latter is the default -in python as used above). +src_id (this is the default in python). Use |nvim_buf_clear_highlight()| to +clear highlights from a specific source, in a specific line range or the +entire buffer by passing in the line range 0, -1 (the latter is the default in +python as used above). An example of calling the api from vimscript: > @@ -655,14 +654,14 @@ nvim_get_chan_info({chan}) *nvim_get_chan_info()* stderr of this Nvim instance "socket" TCP/IP socket or named pipe "job" job with communication over its stdio - "mode" how data received on the channel is interpreted "bytes" send and recieve raw bytes "terminal" a |terminal| instance interprets ASCII sequences "rpc" |RPC| communication on the channel is active "pty" Name of pseudoterminal, if one is used (optional). On a POSIX system, this will be a device path like /dev/pts/1. Even if the name is unknown, the key will still be present to indicate a pty is used. This is currently the case when using winpty on windows. "buffer" buffer with connected |terminal| instance (optional) "client" information about the client on the other end of the RPC channel, if it has added it using |nvim_set_client_info|. (optional) + "mode" how data received on the channel is interpreted "bytes" send and recieve raw bytes "terminal" a |terminal| instance interprets ASCII sequences "rpc" |RPC| communication on the channel is active "pty" Name of pseudoterminal, if one is used (optional). On a POSIX system, this will be a device path like /dev/pts/1. Even if the name is unknown, the key will still be present to indicate a pty is used. This is currently the case when using winpty on windows. "buffer" buffer with connected |terminal| instance (optional) "client" information about the client on the other end of the RPC channel, if it has added it using |nvim_set_client_info()|. (optional) nvim_list_chans() *nvim_list_chans()* Get information about all open channels. Return: ~ Array of Dictionaries, each describing a channel with the - format specified at |nvim_get_chan_info|. + format specified at |nvim_get_chan_info()|. nvim_call_atomic({calls}) *nvim_call_atomic()* Calls many API methods atomically. |