Paul Jolly wrote:
> > It would only be triggered when Vim is not halfway a mapping, ":normal",
> > feedkeys(), autocommand, etc.
>
> Perfect.
>
> > There will be no "leave", because the user then already typed something
> > and I don't see what you can do. Perhaps what you want is a way to
> > obtain the status, thus after triggering the event Vim would keep this
> > "safe" state until input is found (other then processing messages).
> > Hmm, when invoking a callback you would be temporarily outside of this
> > "safe" state, since you are executing a sequence of commands, but that's
> > where you would check... That's a catch 22.
>
> Yeh this is where I think it gets tricky. But I think we could treat
> the "obtaining of the status" as an optimisation that we don't
> necessarily need. Reason being, if the handling of a message from
> govim is itself treated as "unsafe", then we know we will get a "safe"
> autocommand callback soon after. So the command/whatever we were asked
> to "schedule" by govim will simply happen a tiny bit later than if
> were were able to query the "safe" state. Would that work?
>
> > > I think we would also need a way to ask "are there any current
> > > autocommands?". The logic would become:
> >
> > Why autocommands? We also have callbacks that might be busy.
>
> You're quite right; for some reason I unnecessarily constrained my
> thinking to autocommands.
>
> > What if another plugin is doing a ch_evalexpr()? I suppose that doesn't
> > interfere with what your plugin is doing.
>
> It could/would interfere... and it's a problem with the approach I've
> described, that's for sure because all I'm doing is:
>
> let s:activeGovimCalls += 1
> let l:resp = ch_evalexpr(s:channel, a:args)
> let s:activeGovimCalls -= 1
>
> Clearly I can't "control" ch_evalexpr calls in any other plugins.
>
> So generally speaking, I think we need some help from Vim itself here:
> either to keep track of ch_evalexpr calls (and anything else?) or by
> fleshing out the "safe" autocommand above. Or maybe both?
So roughly:
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)
Trigger autocommand when entering "safe" state:
- NormalSafe
- InsertSafe
- CmdlineSafe
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
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.
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()
--
If you're sending someone Styrofoam, what do you pack it in?
/// 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/201909131824.x8DIOS3R001045%40masaka.moolenaar.net.
