> 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.

Raspunde prin e-mail lui