aboutsummaryrefslogtreecommitdiff
path: root/runtime/syntax/java.vim
diff options
context:
space:
mode:
authorJustin M. Keyes <justinkz@gmail.com>2017-03-13 15:02:37 +0100
committerJustin M. Keyes <justinkz@gmail.com>2017-04-28 19:14:34 +0200
commit3ea10077534cb1dcb1597ffcf85e601fa0c0e27b (patch)
treea043bcdda63a9f3e4c3475dd6371ebb2c2324ddb /runtime/syntax/java.vim
parent7044aa6e8256844bc1bd23eb61d4a41ca6d418d0 (diff)
downloadrneovim-3ea10077534cb1dcb1597ffcf85e601fa0c0e27b.tar.gz
rneovim-3ea10077534cb1dcb1597ffcf85e601fa0c0e27b.tar.bz2
rneovim-3ea10077534cb1dcb1597ffcf85e601fa0c0e27b.zip
api: nvim_get_mode()
Asynchronous API functions are served immediately, which means pending input could change the state of Nvim shortly after an async API function result is returned. nvim_get_mode() is different: - If RPCs are known to be blocked, it responds immediately (without flushing the input/event queue) - else it is handled just-in-time before waiting for input, after pending input was processed. This makes the result more reliable (but not perfect). Internally this is handled as a special case, but _semantically_ nothing has changed: API users never know when input flushes, so this internal special-case doesn't violate that. As far as API users are concerned, nvim_get_mode() is just another asynchronous API function. In all cases nvim_get_mode() never blocks for more than the time it takes to flush the input/event queue (~µs). Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if e.g. `d` is operator-pending. Closes #6159
Diffstat (limited to 'runtime/syntax/java.vim')
0 files changed, 0 insertions, 0 deletions