> One question about the "safe" state autocommand you're proposing: > would this only be triggered when there are no other autocommands in > progress? i.e. the "safe" autocommand itself will be the only > autocommand at the time when called? If so, that would work. Would > there also be an autocommand for when you are leaving this "safe" > state?
It would only be triggered when Vim is not halfway a mapping, ":normal", feedkeys(), autocommand, etc. There will be no "leave", because the user then already typed something and I don't see what you can do. Perhaps what you want is a way to obtain the status, thus after triggering the event Vim would keep this "safe" state until input is found (other then processing messages). Hmm, when invoking a callback you would be temporarily outside of this "safe" state, since you are executing a sequence of commands, but that's where you would check... That's a catch 22. > > This would be too long when in Insert mode or editing the command line, > > thus perhaps we need events for these as well. > > I think we would also need a way to ask "are there any current > autocommands?". The logic would become: Why autocommands? We also have callbacks that might be busy. > 1. if a "sensitive" call from govim -> Vim comes in and there are no > active ch_evalexpr calls from Vim -> govim, no current autocommands > and we are in the "safe" state, then handle immediately > 2. if, however, there are either active ch_evalexpr calls, or current > autocommands or we are not in the "safe" state, add the request to the > end of a pending queue > 3. when the number of active ch_evalexpr calls reaches zero, there are > no current autocommands and we again enter a "safe" state, process the > pending queue in order > > That way, the edges that move us from >0 to 0 active ch_evalexpr > calls, and the "safe" autocommand, would be the triggers for point 3 > and processing the pending queue. > > For now we try the original scheme I described and report back with > any findings. But very happy to continue discussions on better > approaches people might have. What if another plugin is doing a ch_evalexpr()? I suppose that doesn't interfere with what your plugin is doing. -- Eagles may soar, but weasels don't get sucked into jet engines. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/201909122034.x8CKYBIx028912%40masaka.moolenaar.net.