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

Improvement: choose-option: support default values, for preselected options, including with --multi #98

Closed
balupton opened this issue Dec 1, 2021 · 1 comment
Labels
enhancement Improvement or suggestion

Comments

@balupton
Copy link
Member

balupton commented Dec 1, 2021

Currently in setup-utils --configure if one already has some SETUP_UTILS defined, they will be lost. Instead, there should be a way to pass default vaults to choose-option, either newline separated --default=<values> or multitiple --default=<vlaue> --default=<value> style, or another choose-option --multi -- <option> <option> -- <default> <default> at the end.

@balupton balupton added the enhancement Improvement or suggestion label Dec 3, 2021
@balupton balupton added this to the --default for all! milestone Dec 5, 2021
@balupton balupton changed the title Allow default values in choose-option, such that multiple values can be preselected when using --multi Improvement: choose-option: support default values, for preselected options, including with --multi Sep 9, 2023
balupton added a commit that referenced this issue Oct 8, 2023
to make this possible, I had to close #98 which enables --default(s) usage on `choose-menu` and `choose-option`

this still requires tests to be added
balupton added a commit that referenced this issue Oct 8, 2023
to make this possible, I had to close #98 which enables --default(s) usage on `choose-menu` and `choose-option`

this still requires tests to be added
balupton added a commit that referenced this issue Oct 8, 2023
to make this possible, I had to close #98 which enables --default(s) usage on `choose-menu` and `choose-option`

this still requires tests to be added
balupton added a commit that referenced this issue Oct 16, 2023
to make this possible, I had to close #98 which enables --default(s) usage on `choose-menu` and `choose-option`

this still requires tests to be added
@balupton
Copy link
Member Author

balupton commented Oct 19, 2023

This will be landing soon, just need to write tests for it.

went with --default=<value> --defaults=<value>\n<value>

balupton added a commit that referenced this issue Oct 24, 2023
- dorothy:
    - a single menu prompt for shell selection, instead of a confirm for each shell
- choose-option:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - use choose-menu hints when they make sense
    - don't output colours if we aren't meant to
- choose-menu:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - unless `--no-hints` is provided, there will be will a hint line
    - selected items are now bold, to distinguish between current item (especially important for non-multi menus with default)
    - menu results are now visible when called standalone, as the tty clear/finish now happens before the stdout output
    - don't output colours if we aren't meant to
    - up and down actions now traverse the boundaries
    - if `--multi`, then `a` now selects all, and `d` now selects none
    - performance has improved, as we now just do a single tty output
- echo-style:
    - support `--color`, `--colors`, `--no-color`, `--no-colors`, and `--colors=yes|no` (`--color=...` and `--nocolor=...` are still stylised correctly)
balupton added a commit that referenced this issue Oct 24, 2023
- dorothy:
    - a single menu prompt for shell selection, instead of a confirm for each shell
- choose-option:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - use choose-menu hints when they make sense
    - don't output colours if we aren't meant to
- choose-menu:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - unless `--no-hints` is provided, there will be will a hint line
    - selected items are now bold, to distinguish between current item (especially important for non-multi menus with default)
    - menu results are now visible when called standalone, as the tty clear/finish now happens before the stdout output
    - don't output colours if we aren't meant to
    - up and down actions now traverse the boundaries
    - if `--multi`, then `a` now selects all, and `d` now selects none
    - performance has improved, as we now just do a single tty output
- echo-style:
    - support `--color`, `--colors`, `--no-color`, `--no-colors`, and `--colors=yes|no` (`--color=...` and `--nocolor=...` are still stylised correctly)
balupton added a commit that referenced this issue Oct 24, 2023
- dorothy:
    - a single menu prompt for shell selection, instead of a confirm for each shell
- choose-option:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - use choose-menu hints when they make sense
    - don't output colours if we aren't meant to
- choose-menu:
    - support `--default=<item>` and `--defaults=<item>\n<item>`
    - unless `--no-hints` is provided, there will be will a hint line
    - selected items are now bold, to distinguish between current item (especially important for non-multi menus with default)
    - menu results are now visible when called standalone, as the tty clear/finish now happens before the stdout output
    - don't output colours if we aren't meant to
    - up and down actions now traverse the boundaries
    - if `--multi`, then `a` now selects all, and `d` now selects none
    - performance has improved, as we now just do a single tty output
- echo-style:
    - support `--color`, `--colors`, `--no-color`, `--no-colors`, and `--colors=yes|no` (`--color=...` and `--nocolor=...` are still stylised correctly)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement or suggestion
Development

No branches or pull requests

1 participant