vim.ui.input usage for plugin authors

[olacin]

👋 Hi,

First of all I'd like to say thank you for writing dressing.nvim, it is an awesome plugin. As a plugin author, I have myself developed telescope-cc.nvim that leverages vim.ui.input.

In order for my plugin users to be able to use dressing.nvim, I've written an action that uses callbacks due to vim.ui.input being async in dressing. For some reason, some of my contributors reported a possible bug on how modes are handled:

• When asking for scope, the prompt starts in normal mode, when it should be in insert mode, forcing me to make an extra step before writing. I cannot think of a reason why this would be desired, so I suspect it's a bug.
• when exiting the prompts after committing, it leaves you in insert mode, forcing me to take an extra step before I continue. It doesn't respect the mode I was in when calling the plugin. Again, this seams like a bug

I have tried reproducing the issue and although my config has the default start_mode to insert, it seems I have to hit i to enter insert mode in the first window opened (next ones seems to be working fine). I suspect this line to execute after the chain of prompts ended since it goes to insert mode when the action is over, instead of staying in normal mode. It seems to be only with dressing since using the native vim.ui.input works fine.

This function is what uses vim.ui.input. Would you have any idea on how I can fix this ?

Thank you so much ! 🙏

[stevearc]

Difficult to say exactly what's going on because I don't know all the code that's running. Certainly if we are not respecting the start_mode then that's a bug, and we should also be restoring the mode you were in when you called vim.ui.input. In your particular case, I suspect you are in insert mode while calling vim.ui.input because in the demo video on your repo it looks like you're calling it from telescope where your cursor is in insert mode.

If you can get me a minimal repro using the bug report template I can look into it some more.