Paul Jolly wrote:
> > > Does this sound OK?
> >
> > I decided to give it a go and did an implementation of SafeState.
> > It triggers in Normal, Insert and Command-line mode when nothing is
> > pending. And when a blocking channel call has been made, where the
> > state was safe before blocking, so that when something is postponed it
> > can be handled afterwards.
> >
> > It may be that we need to check more conditions whether it is actually
> > "safe". And some things depend on what the requirements for "safe" are.
> > E.g. currently it is not checking for Visual mode, you can use mode()
> > for that. And it doesn't check whether the screen is scrolled (not sure
> > how you would check for that, might need the state() function).
> >
> > When SafeState is triggered after the blocking channel call, we are in
> > the input loop, thus no screen update will take place. You can use
> > :redraw, but in Command-line mode that might not work well.
> >
> > Anyway, please try it out, so we can decide whether we can keep
> > SafeState, modify it, or perhaps drop it.
>
> Thanks, Bram. Sorry, not been able to keep up with the threads and progress!
>
> Very keen to give this a try, thanks.
>
> Two questions.
>
> 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.
The SafeState event is always triggered when going through the main
loop and nothing is pending, thus every time after the user finishes
some action. That can be after every typed letter.
> Secondly, in the following situation, when does SateState get triggered?
>
> 1. user makes change in insert mode
> 2. listener_add callback fires and make ch_evalexpr call
> 3. Vim receives and handles a channel-based message; let's just assume
> we put this work onto a pending queue (in the absence of safeState())
> 4. ch_evalexpr returns
> 5. the listener_add callback returns
>
> I'm assuming the answer is "after step 5" - but is it immediately
> after the listener_add callback returns?
It would be at 4. when ch_evalexpr() is done and leaves the blocking
loop. Then listener_add() is still active then, thus it might be too
early to run the work.
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).
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.
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.
--
We're knights of the Round Table
Our shows are formidable
But many times
We're given rhymes
That are quite unsingable
We're opera mad in Camelot
We sing from the diaphragm a lot.
"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/201909161428.x8GESJCM010307%40masaka.moolenaar.net.
