Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for nvim lua's vim.ui #40

Open
ModProg opened this issue Jul 27, 2022 · 4 comments
Open

Support for nvim lua's vim.ui #40

ModProg opened this issue Jul 27, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@ModProg
Copy link
Contributor

ModProg commented Jul 27, 2022

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
Copy link
Owner

noib3 commented Jul 27, 2022

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

@noib3 noib3 added the enhancement New feature or request label Jul 27, 2022
@ModProg
Copy link
Contributor Author

ModProg commented Jul 27, 2022

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
Copy link
Owner

noib3 commented Jul 27, 2022

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
Copy link
Contributor Author

ModProg commented Jul 27, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants