> > Firstly, is there still a plan for the safeState/state/whatever > > function? Because without it, if a message arrives at a "safe" time we > > need something unsafe to happen before it will be run? > > Yes, adding the state() function would be needed. It's a bit of work, > not sure when I get to it.
Understood. From our side I think we would need this in place before being able to switch over because something like this would I think be noticeable. Would a simple first cut of this be to expose the number of blocked calls, e.g. ch_evalexpr and friends? We could then grow/add to this function as we learn/experiment more? <snip> > Thinking about this, we should probably trigger SafeState later. So we > would set a flag in ch_evalexpr() that we did block, and check for that > flag when back in the main loop, after the callback finished. > > Hmm, perhaps we don't need that flag, we could always trigger SafeState, > and you need to make sure you added the autocommand only when you > actually have some work pending. That's tricky, if you are not careful > the event is triggered very often (looping may only wait for 20 msec > before trying again, e.g. checking for a job does polling). I'm not familiar with Vim's internals: please can you explain the different loops you're referring to here? > Another way would be that the plugin explicitly asks for triggering the > event. Thus if you add something to the work queue you call some > function and the event is triggered once as soon as the safe state is > reached in the waiting loop. For the higher level > (Normal/Insert/Commandline mode) it would still always be triggered. > > I guess that just relying on adding the autocommand when it's needed is > the simplest, it does not require a new mechanism. It's up to the > plugin then to clean up the autocommand when it's not needed. Assuming the adding/removing of an autocommand is not too expensive, that sounds like a reasonable first approach. > Also, perhaps we should have a different event for when it is triggered > from the waiting loop, instead of from the toplevel, since Vim is in a > different state. Per above, I'd be grateful if you could explain the significance of these different loops. Many 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/CACoUkn5J_HvfZmbR2CCx0iEpErfDfV4jPT__BGjetLqvLz7F7g%40mail.gmail.com.
