mirror of
https://github.com/neovim/neovim.git
synced 2024-12-29 14:41:06 -07:00
2a3bcd1ff8
With the old behavior, if a GUI makes a blocking request that requires user
interaction (like nvim_input()), it would not get any screen updates.
The client, not nvim, should decide how to handle notifications during a
pending request. If an rplugin wants to avoid async calls while a sync call is
busy, it likely wants to avoid processing async calls while another async call
also is handled as well.
This may break the expectation of some existing rplugins. For compatibility,
remote/define.vim reimplements the old behavior. Clients can opt-out by
specifying `sync=urgent`.
- Legacy hosts should be updated to use `sync=urgent`. They could add a flag
indicating which async methods are always safe to call and which must wait
until the main loop returns.
- New hosts can expose the full asyncness, they don't need to offer both
behaviors.
ref #6532
ref #1398
|
||
|---|---|---|
| .. | ||
| autoload | ||
| colors | ||
| compiler | ||
| doc | ||
| ftplugin | ||
| indent | ||
| keymap | ||
| macros | ||
| pack/dist/opt | ||
| plugin | ||
| syntax | ||
| tutor | ||
| bugreport.vim | ||
| CMakeLists.txt | ||
| delmenu.vim | ||
| filetype.vim | ||
| ftoff.vim | ||
| ftplugin.vim | ||
| ftplugof.vim | ||
| indent.vim | ||
| indoff.vim | ||
| macmap.vim | ||
| makemenu.vim | ||
| menu.vim | ||
| mswin.vim | ||
| nvim.desktop | ||
| nvim.png | ||
| optwin.vim | ||
| rgb.txt | ||
| scripts.vim | ||
| synmenu.vim | ||
| vimrc_example.vim | ||
