Hi Bram, Thanks for taking the time to put together the proposal.
> Add a safeState() function, which returns true when: > - not halfway a mapping or stuffed command > - no operator pending > - not executing autocommand > - no autocomplete active perhaps? > - not blocked on waiting, e.g. ch_evalexpr() > - not in a nested callback (if that is even possible) Just to confirm: this function would return true in a channel callback handler (assuming there is nothing else going on). Because in a channel callback handler, as you mention below, is the place that we'd want to call this function and want to benefit from being able to immediately callback to govim if it was safe to do so. > Trigger autocommand when entering "safe" state: > - NormalSafe > - InsertSafe > - CmdlineSafe To keep things simple, do we need the three separate autocommands? Would one "safe" not be enough? Or are you doing this so that the plugin doesn't additionally need to check "which mode are we in?" > So that a plugin can: > - When callback is invoked and safeState() returns false, add to work queue > - When *Safe autocommand event triggers, process work queue Modulo the question above about the separate autocommands, sounds good. > Perhaps safeState() should have an argument about what is considered > safe. E.g. Command-line mode might not be safe. Although mode() could > be used for that. In fact, mode() contains more detail about the state, > what we don't have from there is whether a mapping is active or > something else that doesn't require user interaction. > > Or the return value could be a list of what "unsafe" things are > currently happening. Although that might make it difficult to decide > when to trigger the autocommand. I'm all for keeping this simple for now :) We won't be using the distinction between the three separate autocommands and for now, we're simply looking for a "safe/not safe". But it's highly likely we're not thinking as far ahead as you :) > An alternative is a state() function that returns flags for what is > active: > m inside mapping > x executing command (something in stuff buffer) > a autocommand busy > w waiting in channel function, such as ch_evalexpr() > c in callback, repeated when nesting > > Then trigger a StateChange autocommand when this value changes? Might > be triggered too often. Well, could use the pattern to define what to > wait for. More like StateLeave then, e.g.: > au StateLeave w call WaitEnded() Per above, I think all we (govim) are currently after is to know whether, when we call sateState() or whatever, there are currently any blocked ch_evalexpr calls, because our current approach only works for the ch_evalexpr calls we (govim) have made. We'd be making this call from within the channel callback handler. So the only possibility (at least as far as I understand it) is that things like autocommands, functions, commands etc could only, at this point, be blocked if they are using ch_evalexpr. Or is that not the case? It's quite possible there are other blocking calls I'm not aware of, so please only consider my comments here as seeking to clarify what we are trying to solve for: you have a far better and wider grasp of the problems involved and I understand you're trying to solve for other situations too! Thanks, Paul -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn5G78VKfartbax%3DYki%2Bw%3D-0EJxYUE430iJe5%2BOSAs10xQ%40mail.gmail.com.
