[vim/vim] [Feature Request] Synchronous version of popup_menu() as alternative to inputlist() (#6534)
Ben Jackson
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
popup_menu is a nice UI for selecting from a list of things, but it's tricky to use due to the response only being delivered asynchronously via a callback. I'd like to be able to interchange inputlist with a popup menu version of that without significant code restructuring.
The precise use case is as follows:
currently in vimspector, when you start debugging, you get asked which debug configuration you wish to use. This uses inputlist():
But from a UI perspective, it's attractive to look into something like this:
The challenge being that Vimspector needs to ask for input and get the result synchronously (as you get with inputlist). The async callback progrming model for the menu requires quite significant restructuring of the code flows.
Describe the solution you'd like
I'd like to be able to do something like this:
if exists( '*popup_menu' ) let selection = popup_inputlist( ... ) else let selection = inputlist( ... ) endif let item_selected = list_of_options[ selection - 1 ] " or whatever " etc.
On the face of it, this would seem plausible in the sense that the input is already being filtered by the filter function and so execution is logically synchronous, and that popup_menu and inputlist seem to share similar properties in terms of use case.
Describe alternatives you've considered*
I could restructure the vimspector code to always work as if asking for user input is async, rather than the way it is today expecting to get synchronous response.
Additional context
It looks like there is a precedent in some code for synchronously waiting for a menu result when mousemodel is popup and we get a right-click, or :popup... pum_show_popupmenu and friends.
If it is very hard to do, or very bad for other reasons, then i'm sure i can manage the flow in vimspector with some refactoring (or just stick to inputlist), but wonder if this is possible.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Marco Trosi
I also need a "wait" option for the popup_menu() & Co. functions, to make them "synchronous".
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
@puremourning a workaround, somewhat ugly, but should work:
vim9script
var winid = popup_create(['red', 'green', 'blue'], {})
while 1
redraw
var ch = nr2char(getchar(0))
if ch == 'q' || ch == "\<ESC>"
popup_close(winid)
break
endif
sleep 15m
endwhile
echo "I should be visible after popup is closed!"
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Instead of using getchar(), it's better to have the callback store the result in a variable, and check that variable in the wait loop.
Then using the cursor to select an entry will work.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ben Jackson
both solutions use busy-waiting. wouldn't sleeping in select()/poll()/etc. waiting for input be better?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marco Trosi
Just stumbled upon my function that I wrote last year that I can't finish in a nice way because Vim doesn't have a synchronous popup_menu() or "wait" option for it. I'm just commenting again, hoping that it will be implemented.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
This can be useful. I wonder what implementation would work best. Simplest is to only do this for popup_menu(). But what if someone implements this in another way? We could add a "wait for any popup to be closed" function. That avoids the busy-waiting. It does require checking that the right popup was closed and it's callback was invoked. An even more generic way would be to wait for any callback to be invoked. Then you can also break out when a timer expires, for example.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ben Jackson
For me, as I put in the original I actually don't want a callback, just an API similar to inputlist(). The awkwardness with a callback in this case comes from managing global state to get the result.
Alternatively, we could take your second idea (eg a popup_wait(winid) that waits for that popup to close and returns the result of the close callback for winid. That would also work easily and obviously.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> For me, as I put in the original I actually don't want a callback,
> just an API similar to inputlist(). The awkwardness with a callback in
> this case comes from managing global state to get the result.
>
> Alternatively, we could take your second idea (eg a
> the result of the close callback_ for winid. That would also work
> easily and obviously.
It still requires a close callback to handle the result.
If we only want to do this for popup_menu() it might be possible, but
that is a very specific solution. I am sure plugin writers will son
come up with reasons for a more generic solution.
Since Vim will be doing a blocking wait, using a global variable should
not be much of a problem. It should be possible to use a script-local
variable in most cases.
--
hundred-and-one symptoms of being an internet addict:
174. You know what a listserv is.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marco Trosi
is a "wait" flag/parameter possible for popup_menu() and Co?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ben Jackson
It may be asking too much, or going too far. But this has the hallmarks of something that promises/futures were trying to solve. My proposed 'popup_wait(winid)' is not much different from a future_get(). And returning from the callback a value could be achieved with a 'promise_put()'.
Just a thought.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.