Alternative to `utils::menu()`?

[jennybc]

Semi-related to #151

More than once, when working on package UI, I've wished for a better version of utils::menu()?

Do you think that could fit here? If so, I'll start to jot down a wish list as specifics come up.

[gaborcsardi]

Yes, definitely. Some requirements would be very helpful, thanks!

#119 is related.

[jennybc]

OK, I will start adding thoughts incrementally.

Similar to rlang::abort()'s approach to structured error messages, there should be scaffolding for the usual elements needed when asking a question. Meaning:

HEADER where we presumably give some context and information to guide the user's choice

ACTUAL QUESTION?
1: pirates
2: ninjas

As it stands with menu(), one has to print the HEADER and ACTUAL QUESTION separately, which introduces the possibility of the question appearing without these elements, in more complicated situations. Of course, this should never happen, but sometimes it does (for users or, more often, during development experiments).

I'm using rlang::inform() more and more, directly and indirectly, which introduces the issue of standard output vs. standard error. Often there's some package- or function-level verbosity control in the picture as well.

It would be best if the front matter were handled holistically, with the rest of the menu-making elements, e.g. choices. This also seems to fit nicely with the semantic UI goals.

Yes, I know about the title argument of menu(). That's not very satisfying if you're using cli (or other, earlier methods) to create a nice-looking UI.

[jennybc]

It feels like there should be a standard (probably optional) footer, explaining how to decline to make a choice, e.g. ESC or entering 0. Styled in a suitably subtle way.

[jennybc]

It would be great to have a default choice that one could accept just by pressing "enter".

[jennybc]

The "enter this" codes should? could? be customizable:

You are going to live on an island with precisely 1 fruit tree for the rest of your life.

Which do you prefer?
a: apple
b: banana

[jennybc]

Concrete example where one might want to customize the selection entries:

Here it feels weird to type '9' to select issue 833. Why not just accept '833'? Maybe in this case, the short numbers are still better, but I figure it's still a decent motivating example.

[danielvartan]

This would be very helpful. Any chance that will be available on the next version of cli?

[CoryMcCartan]

Some things that I think would make menus more user-friendly but which may (probably?) be harder to implement consistently across all terminal types/environments. These would also go beyond just minor improvements to menu(), and so may not make sense.

1. Visual feedback in the list about which choice is currently selected (e.g. an * next to the default). Pressing 'enter' would select the marked option. Scanning back and forth to make sure the typed selection matches the row you really want slows user input
2. Related to this, the ability to navigate the menu with arrow keys, like any non-terminal menu on a computer.
3. An option to allow for selections without pressing enter? Probably a more specialized use case, but for many repeated inputs with <10 options (or <26 if you label with letters), where the cost of a typo isn't too large, this would also speed input

Presumably for terminals which can't have earlier parts overwritten, 1 and 2 would be disabled.

[gaborcsardi]

@CoryMcCartan Good ideas!

1. can be implemented on every UI.
2. can be only implemented in terminals that support moving the cursor around, i.e. not in RStudio, R.app, RGui, emacs, etc.
3. the same applies here.

Given that few people would benefit from 2-3 I would not make them a priority for the first implementation.

[CoryMcCartan]

Thank you, that makes sense! Just to be clear (and this may not change the doability / priority of it), for 2 the cursor itself wouldn't need to move, you'd just need to be able to listen for keypresses at the prompt & update the visual marker in 1 accordingly.

[gaborcsardi]

To update the visual marker you need to move the cursor to the marker first.