Thanks, Bram. > > Things can go wrong <snip> > > I think that is only true if the callback does something involving a > blocking wait. Such as that ch_evalexpr(). So the problem is not > invoking the listener callback itself, but what happens inside the > callback. There are many callbacks these days, thus this can happen in > many places and there is not much point for Vim to do something for > that. We can document where a blocking wait happens, which is where > other callbacks can be invoked, possibly leading to recursive calls.
Absolutely. I was just using this as an example. We do indeed see this in many different situations. > > Any thoughts on the above analysis/suggestion? > > I think you are correct that you need to look at places with a blocking > wait where a callback would cause trouble. Then adding the event to a > queue, instead of doing the work immediately, and check that queue for > work after the blocking wait would indeed be the best solution. > > If this gets too complicated, my suggestion to add an autocommand event > when Vim is in a "safe" state would help. E.g. when waiting for the > start of a command in Normal mode (without a register, count, pending > operator, etc.). Perhaps even when not halfway a mapping, thus actually > waiting for they user to type. https://github.com/govim/govim/pull/523 has a WIP version of the approach I described and it appears to be working well (it's currently pending a few fixes from gopls which is why the build is broken). We will need to give it some more exposure to CI, but for now things are working well on my local machine. One question about the "safe" state autocommand you're proposing: would this only be triggered when there are no other autocommands in progress? i.e. the "safe" autocommand itself will be the only autocommand at the time when called? If so, that would work. Would there also be an autocommand for when you are leaving this "safe" state? > This would be too long when in Insert mode or editing the command line, > thus perhaps we need events for these as well. I think we would also need a way to ask "are there any current autocommands?". The logic would become: 1. if a "sensitive" call from govim -> Vim comes in and there are no active ch_evalexpr calls from Vim -> govim, no current autocommands and we are in the "safe" state, then handle immediately 2. if, however, there are either active ch_evalexpr calls, or current autocommands or we are not in the "safe" state, add the request to the end of a pending queue 3. when the number of active ch_evalexpr calls reaches zero, there are no current autocommands and we again enter a "safe" state, process the pending queue in order That way, the edges that move us from >0 to 0 active ch_evalexpr calls, and the "safe" autocommand, would be the triggers for point 3 and processing the pending queue. For now we try the original scheme I described and report back with any findings. But very happy to continue discussions on better approaches people might have. 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CACoUkn5VLf45wzpcTQoH88TcSHxZfS%3DmR2MYNoXDyWCufaN5Qw%40mail.gmail.com.
