search

noib3 / nvim-oxi

:link: Rust bindings to all things Neovim
https://crates.io/crates/nvim-oxi
MIT License
888 stars 44 forks source link

Support for nvim lua's `vim.ui` #40

Open ModProg opened 2 years ago

ModProg commented 2 years ago

One great thing to have would be https://neovim.io/doc/user/lua.html#lua-ui Sadly they are only usable with callbacks, but with #38 this could maybe be made to be async instead.

Especially because they can be overridden using plugins like telescope.

noib3 commented 2 years ago

I'm not sure this should be made async even if it was currently possible.

ModProg commented 2 years ago

I don't need to have them be async, async would just make them easier to use to avoid ending up in callback hell, e.g. if you want to call a bunch of them in sequence. Maybe there could be a general way to await the callback functions in the neovim api.

noib3 commented 2 years ago

Right, but not all callbacks serve the same purpose.

Some are used to save a function to be executed later in response to an event or a command (like those bound to keymaps or autocommands), some are just a way to fake async to avoid blocking the thread, usually used when dealing with IO (like those in :h lsp-handler).

38 would be for the latter group, but I don't think the callbacks used in vim.ui.* fall into this category, hence why I'd leave them as callbacks.

ModProg commented 2 years ago

Makes sense, I think there are both use cases for the ui callbacks.

I think there are two use cases:

  1. query for some input and afterwards do some processing on it
  2. query some input that is afterwards used in the rest of the code, possibly calling it multiple times (imagine something like npm init where you are asked multiple times for input)

My use case is the latter, I load config files and if they change, I query the user if they want to approve the changes, afterwards I'll continue loading, merging all the configurations that were approved and applying them, so I need to wait for the user to respond for each changed file before I continue executing the function.

Hence, why I wanted these as async.

Obviously these can also be used for a different use case, where you e.g. list a bunch of commands and the user selects one which is then executed.

I think I could use both, and shouldn't be too bad doing it with callbacks.