fix: be more resilient when updating buffer text in the background

[emmanueltouzery]

it's possible to get E565 when updating the buffer due to other user activity (triggering the abolish.vim 'cr' shortcut can do that).

This is really relatively bizarre, but I can in fact reproduce this on-demand in my setup. The stack is...

Error detected while processing User Autocommands for "OverseerListUpdate":
Error executing lua callback: ...r/start/overseer.nvim/lua/overseer/task_list/sidebar.lua:419: E565: Not allowed to change text or change window
stack traceback:
[C]: in function 'nvim_buf_set_lines'
...r/start/overseer.nvim/lua/overseer/task_list/sidebar.lua:419: in function 'render'
...r/start/overseer.nvim/lua/overseer/task_list/sidebar.lua:92: in function <...r/start/overseer.nvim/lua/overseer/task_list/sidebar.lua:91>
[C]: in function 'nvim_exec_autocmds'
...cker/start/overseer.nvim/lua/overseer/task_list/init.lua:14: in function 'rerender'
...verseer.nvim/lua/overseer/component/display_duration.lua:34: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>

To reproduce this... I start a long-running overseer task, so the clock will continuously update in the sidebar. I open the sidebar so the clock is displayed. I go to my normal buffer (not overseer) and type cr in normal mode. This triggers an abolish.vim shortcut (the full shortcut would be crs for instance to coerce the text under the cursor to snake case mode, or crc to camel case for instance).

And that triggers the error in the overseer code that executes in the background. The pcall silences it, makes the update fail, but it'll succeed the next update.

Maybe there are other set_text calls to fix, but this is one that really occurs often and so is really easy to trigger.

This is probably not the "right" fix.. So I'll understand 100% if you reject the PR. I'm not going to find the time to attempt to reproduce this on a clean setup... So if that approach doesn't work for you and you can't think of a better one.. it's maybe better to drop it. Also I guess "abolish is to blame" is likely a good answer too. But putting it out there just in case...

[stevearc]

It was easy to reproduce this, and it turns out there are a lot of things that the operator pending mode breaks (it's not just abolish, you can cause this with a simple ci). You can't switch buffers, windows, change buffer text, start jobs...a lot of things error out. I've added a couple of pcalls to make some of the common background operations fail more gracefully as you've requested, but this seems to be an unfortunate limitation of the internal state of Neovim.

[emmanueltouzery]

thank you. The good news is that after the pcall i had added, i never again got the issue, so at least for my use i think then it's safe. i can see how it might be next to impossible to fix it for all the possible cases, but i guess it's possible to cover it for the "real world" cases.