bew
commented
3 years ago I think the prompt shouldn't have that much logic, also the is_successful parameters name is confusing in my opinion.
What about this alternative: move the possible_selection vec outside of the prompt function, and simply give it as a parameter?
This way:
- The possibles selections stays at the same place where we check the results, I think it's better for locality.
- The prompt function stays simple, no specific logic based on obscure unknown condition (from the point of view of the function).
- Since you know beforehand the various conditions you can request prompt only with the relevant selection!
- The prompt function uses the first possibility as the default, maybe for the case of confocts, the default should be Edit, not No?
Other things I'm thinking:
- for the
possible_selectionvec, does it have to be a vec? We never try to modify it, so it could be a basic array, no? - for the choices, I think it would be more
rusty/rust-liketo use an enum here, not strings. (but it might not be ideal though, if the thing that does the prompt require strings..)
marcusbuffett
Hello!
Currently, the program aborts when there will be a collision with the renamed files. I think it is more convenient to allow the user to fix the current renaming, instead of expecting him to do all the renaming again.
This pull request hides the "Yes" answer when there is a collision with the filenames. This allows the user to select the "Edit" or "Reset" option to fix the collision. When the
--yesoption is given, the program aborts when there is a collision (so that it is never interactive with--yes).I have also changed the color in which the collisions are shown to red so that it is more obvious that something went wrong.