before this change, with vim.ui.input, if the user callback triggers a vim error, dressing would get stuck and all following vim.ui.input invocations would hang/not be processed.
Context
It is possible to reproduce the issue by triggering this vim command:
so we try to close a non-existing vim window. That will fail. But after this, trigger the same command again, and the dressing input prompt will not appear. Because the callback throwing "broke" the dressing logic.
Description
Instead of first invoking the user callback and then scheduling the consumption, invert the order to make sure the user callback failing cannot break the dressing logic.
I considered using pcall to invoke the user callback, but if the user callback has an error, something should fail and the error should be bubbled back to the UI, which does not occur with pcall.
Test Plan
You can run the command I gave as an example twice in row. Without the change, it'll work only the first time. With the change, it'll work twice and more.
before this change, with vim.ui.input, if the user callback triggers a vim error, dressing would get stuck and all following vim.ui.input invocations would hang/not be processed.
Context
It is possible to reproduce the issue by triggering this vim command:
so we try to close a non-existing vim window. That will fail. But after this, trigger the same command again, and the dressing input prompt will not appear. Because the callback throwing "broke" the dressing logic.
Description
Instead of first invoking the user callback and then scheduling the consumption, invert the order to make sure the user callback failing cannot break the dressing logic. I considered using pcall to invoke the user callback, but if the user callback has an error, something should fail and the error should be bubbled back to the UI, which does not occur with pcall.
Test Plan
You can run the command I gave as an example twice in row. Without the change, it'll work only the first time. With the change, it'll work twice and more.