> > > 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?
Most callbacks are invoked from parse_queued_messages(). This is used
when waiting for a key and when sleeping. Only timer callbacks are
called elsewhere (and differently when using the GUI).
> > 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.
It's hard to explain, and it differs per system and whether the GUI is
used. The general idea is "waiting for the user to type a character".
While doing that we trigger timers, read channels and process messages.
--
MAN: Fetchez la vache!
GUARD: Quoi?
MAN: Fetchez la vache!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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/201909161840.x8GIeLql024996%40masaka.moolenaar.net.
