Selective apply of functions to items #1843
Conversation
alternative and more flexibile implementation to fulfil beetbox#1723 Added test case for new input method
preparation to implement interactive selection in modify command
|
I added the interactive mode for both modify and move command now and added a changelog entry. Please review
|
| out_items = [] | ||
| choice = input_options( | ||
| ('y', 'n', 's'), False, | ||
| '%s (Yes/No/Selective)?' % prompt) |
There was a problem hiding this comment.
A tiny thing, but I might find the verb "Select" more intuitive than the noun "Selective".
|
Cool! This is feeling like the right direction. It might make sense to try to unify all the different places where we do confirmation (if there are any others— |
|
I changed "Selective" to "Select items" now, as it more intuitive. |
|
Cool, that helps! Thanks! If we're going to have a noun in the prompt, though, it should be Thanks for being with all the terminology bike-shedding! We're definitely getting closer. |
| out_items = [] | ||
| choice = input_options( | ||
| ('y', 'n', 's'), False, | ||
| '%s (Yes/No/Select items)?' % prompt) |
There was a problem hiding this comment.
Again on the detail-obsession topic: most of the other confirmation prompts in beets seem to have the form "Question? (A/b/c)" rather than "Question (A/b/c)?", so we should probably try for consistency with the placement of the question mark.
Also, we usually format this kind of prompt using just the initial letters, one of which is capitalized to indicate that it's the default. Of course, that isn't as easy to read when the options aren't just Y and N, which are self-evident. It's possible that we need some creativity here—how can we make it clear that there's a default, that you can just type one letter, and yet also that there's a third option?
There was a problem hiding this comment.
That's right. I would like a way which will let you print a help like suggested above
|
On the broader question of what the prompt should look like: let's stick with something simple for now. The plain (colorized) output from >>> beets.ui.input_options(('yes', 'no', 'select'))
[Y]es, No, Select?The capitals, brackets, and colors help suggest that Y and N are options, that Y is the default, and that you can also choose to "select" without being too verbose. Short, off-topic rant: Overall, I'm worried about adding too much complexity to what should be a very simple prompt for most uses. The majority of people will just want to say "yes" or "no" to a listing, so giving a long list of options to read seems like a shame. Git is certainly a counterexample, but IMO option overload is one of the reasons git is so unusable. |
moved question mark and removed word "item"
|
Hi, i changed the prompt to a more common one. I also added some code to catch a KeyboardInterrupt in pkess/catch_keyboardinterrupt. Are there any contradictions to implement it like this? It would suppress the Backtrace on output and exit in a clean way. I could also add a line to tell the user s.th. like "Abort due to CTRL-C" |
|
If you are ok with this implementation, i would like to merge it to master. |
|
Great! Regarding KeyboardInterrupt, I believe we already handle this at the top level (in |
|
Looks good to me after a review, so please do feel free to merge. If you can, at some point, please add a brief note to the docs for |
Conflicts: docs/changelog.rst closes #1843
Documentation for changes by #1843
Most urgently, this function doesn't just work on *items*; it works on arbitrary objects (and, in particular, albums).
To make the docstirng fit in with the standard style.
Yes, please document |
|
Hi, i just opend PR #2280 to meet these requirements |
as suggested in #1838 i implemented a more generic way to let the user select a list of items to apply an action for
@sampsyo implementation for modify and move command will follow if this approach meets your requirements