filter/choose: output the chosen index(s) **or** add display name support

[MattSturgeon]

Is your feature request related to a problem? Please describe. If choices are kinda complex or verbose, I may wish to provide a display name instead just the raw value. Currently I would have to then map my display name back to the actual value.

Describe the solution you'd like An option flag, such as --indexed, which causes the selection's index to be printed, instead of its value.

$ gum choose --indexed \
     "display name one" "display name two" "display name three" "display name four"

  display name one
> display name two
  display name three
  display name four

# Prints:
1

Note: the index should refer to the supplied arguments, not necessarily the order they are displayed in. Unless --ordered is used.

Describe alternatives you've considered

• Allowing a list of display names to be supplied in addition to the values to return.
• Allowing a list of displayname+value pairs to be supplied.

Additional context It would also be nice to show additional context on hover; perhaps if one of the alternatives is used, then the raw value could be displayed below the display-name while that option is selected?

$ gum choose \
    --preview-value \
    --display-names "display name one" "display name two" "display name three" "display name four" \
    "actual_value_1" "actual_value_2" "actual_value_3" "actual_value_4"

  display name one
> display name two
      (actual_value_2)
  display name three
  display name four

# Prints:
actual_value_2

This could be awkward to work with, since you'd need to assume half the arguments are display names and the other half are values...

An alternative:

$ gum choose \
    --no-preview-value \
    --deliminator "=" \
    "display name one=actual_value_1" "display name two=actual_value_2" "display name three=actual_value_3" "display name four=actual_value_4"

  display name one
> display name two
  display name three
  display name four

# Prints:
actual_value_2

This would require additional data-processing on the user's part though... At that point it probably makes more sense to use the indexed approach? Or go all-out and use JSON instead of custom deliminator.

[maaslalani]

I personally prefer the deliminator approach. We can do this quite easily now that we use huh for the choose command.