Paul Jolly wrote:
> 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.
I assume there may be situations where a function wants to know where it
was called from. It could be interactive, the user typed something, or
from a callback. Therefore just true/false is not going to be
sufficient. Thus I tend to go for a state() function, so you can filter
out things you don't care about, e.g.:
if state()->substitute('c', '', 'g') == ''
" nothing relevant busy
> > 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?"
Well, some things might not work well when typing text. But it's true
that we could trigger SafeState and let the autocommand use mode() to
find out where it is.
> > 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?
I found that ch_read() and ch_readraw() can get to the same point of
handling nested messages, if they read JSON.
Inside :sleep messages are also handled, thus if a callback uses :sleep
to wait a bit, it might cause other callbacks to be invoked.
The listener callback can also do something that waits, but I suppose it
is not specific for the listener callback, a timer callback is similar.
Well, the listener callback is invoked when changing text, thus if
somehow a nested callback tries to change text we have a problem.
This more a detection of a state that Vim is busy with a command, then
changing text is not OK.
Another thing that plugins might want to check for: When info is
avaialble and a popup is to be displayed, this probably should not be
done if the screen is shifted up to show messages.
> 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!
I'm trying to avoid adding a safeState() function that we need to keep
tuning, since what is "safe" is hard to define. Safe for what? Thus
letting that up to the plugin writer is probably best, just make it
possible to check the state, more accurately than what mode() does.
Hmm, I wonder if Visual selection is safe for you? Should SafeState
trigger when in Visual mode? we could use the pattern of SafeState to
select when to trigger, or just trigger more often and let the
autocommand use mode() to skip in same states.
--
hundred-and-one symptoms of being an internet addict:
266. You hear most of your jokes via e-mail instead of in person.
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/201909151527.x8FFRDld005758%40masaka.moolenaar.net.
