Justin M. Keyes
Justin M. Keyes
Note that https://github.com/neovim/neovim/pull/30735 is a more incremental approach to this, which should probably be merged first, then this PR can be rebased on it, if needed.
Do we still need this?
Only "async" API functions are non-blocking. Search `:help api` for "async" to see which functions have `Attributes: {async}`. Currently there's only 3: - nvim_input - nvim_get_mode - nvim_get_api_info All other...
> I don't quite understand an idea about a timeout. If the engine is waiting for input this should be known immediately in the engine somehow without a delay (in...
> When that is finished, make this new UI the default and update aloooot of tests. Why shouldn't the default behavior continue to show the messages in the cmdline region?...
Just tried this locally, and I'm very excited for it. The highlighting and pager are very cool. > > Why shouldn't the default behavior continue to show the messages in...
https://github.com/neovim/neovim/pull/31224
Ok, but that means users/plugins will have to create the same kind of wrapper if we don't expose this. That doesn't mean we need to "intend" anything in this PR,...
I thought part of @famiu 's work was to support this "natively". Is this a temporary bridge?
> But tbh, I'm not actually sure what doing it natively would add? Would give support for things like `vim.api.nvim_set_option_value()`, possibly other cases. > I think it would mostly just...