Closed DanielVartanov closed 4 years ago
Noted the coverage thing, will add a test for preserve_order: false
too
@piotrmurach not sure why did it report coverage twice with opposite results, but just in case I've added a test for the case when preserve_order: false
(see https://github.com/piotrmurach/tty-prompt/pull/141/commits/62cde120311334d9cfe23c63d8f8fe8589844834), please let me know whether I should keep it in the PR. Thanks in advance.
Ah, great, that's even better then! I added it as an option only because I wasn't too sure. Awesome, I will update the PR then :+1:
Thanks for bringing this issue up. We need to explore all avenues before settling on a solution 😄
@piotrmurach thanks Piotr, I only ask not to postpone it too much as my deployment automation awaits for it :-)
@piotrmurach I've explored both options: adding index
to Choice
in order to make Choices
sortable and adding selected
to Choice
, I'll create PR's for both and this one will be updated to make the fixed behaviour default.
This pull request is now updated.
PRs https://github.com/piotrmurach/tty-prompt/pull/142 and https://github.com/piotrmurach/tty-prompt/pull/143 represent two paths @piotrmurach has suggested.
But this PR can be merged right away to solve the initial problem.
Describe the change
Preserve initial order of selected choices despite the order they were selected in
Why are we doing this?
Examplary motivation: I'm writing a deployment script which at one point asks the user which commits to cherry-pick for further deployment. The order of the commits is paramount.
Benefits
multi_select
will be a solution to cases where order of chosen items is crucialDrawbacks
Will have to maintain the option in future
Requirements
Put an X between brackets on each line if you have done the item: [X] Tests written & passing locally? [rubocup reports 2000+ offenses, but they don't seem to be related to this PR] Code style checked? [X] Rebased with
master
branch? [X] Documentation updated?