package vcaml
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=d30d1858696f21cb2863ff1a3c39fc9b12c488aa5328073e300ec852d2716a1e
md5=f667331f1f877114bbfdaaf078159581
doc/vcaml/Vcaml/Buf/index.html
Module Vcaml.Buf
Source
val get_lines :
buffer:t ->
start:int ->
end_:int ->
strict_indexing:bool ->
string list Core.Or_error.t Api_call.t
val set_lines :
buffer:t ->
start:int ->
end_:int ->
strict_indexing:bool ->
replacement:string list ->
unit Core.Or_error.t Api_call.t
val attach :
?opts:(Msgpack.t * Msgpack.t) list ->
Vcaml__.Types.client ->
buffer:which_buffer ->
send_buffer:bool ->
Event.t Async.Pipe.Reader.t Async.Deferred.Or_error.t
Attach to an existing buffer and receive a pipe of updates pretaining to this buffer.
The opts
parameter is currently unused but may become used by neovim in the future.
This function returns a regular Deferred.t
instead of an api_call
because it is impossible to execute atomically -- due to potential race conditions between multiple attaches and detaches, this function is written as multiple api calls to neovim that are sequenced according to Throttle.Sequencer
. This has the side effect of potentially running Async cycles during execution, which may in turn invoke other neovim operations, violating the atomicity guarantee of Api_call
.
Attaching to a buffer is unlikely to race with anything. The only operation that may interfere with the buffer attach is if the buffer is deleted or otherwise stops broadcasting while the attach is in flight. Depending on the exact ordering, then, one of two things may happen:
- If the delete occurs before the attach completes, then the attach will fail with a ``nonexistent buffer'' error.
- If the attach completes first, then it will receive a detach message immediately and close itself.
Both cases are ones the application should be prepared to handle.
nvim_buf_detach
isn't directly exposed because it would detach all attached clients. Instead, simply close the returned pipe.