search

commitizen / cz-cli

The commitizen command line utility. #BlackLivesMatter
http://commitizen.github.io/cz-cli/
MIT License
16.73k stars 551 forks source link

add visual aids to indicate exhaustion of options #784

Open waynevanson opened 3 years ago

waynevanson commented 3 years ago

When I scroll all the way down to revert, it cycles down to feat. I can't easily figure out if I've exhausted all the options

This is from the perspective of a new user.

I would love to see one of two changes:

Option One

Pressing down at the bottom places the cursor with feat at the top of the list. Currently it selects feat but without doesn't indicate that it's the end of available options.

? Select the type of change that you're committing: (Use arrow keys)
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 
  build:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) 
  ci:       Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) 
  chore:    Other changes that don't modify src or test files 
❯ revert:   Reverts a previous commit 
? Select the type of change that you're committing: (Use arrow keys)
❯ feat:     A new feature 
  fix:      A bug fix 
  docs:     Documentation only changes 
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 
  build:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)

Option 2

Add a blank line at the end to signify we're at the end of possible options.

? Select the type of change that you're committing: (Use arrow keys)
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 
  build:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) 
  ci:       Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) 
  chore:    Other changes that don't modify src or test files 
❯ revert:   Reverts a previous commit 
? Select the type of change that you're committing: (Use arrow keys)
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 
  build:    Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) 
  ci:       Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) 
  chore:    Other changes that don't modify src or test files 
  revert:   Reverts a previous commit 

❯ feat:     A new feature 
  fix:      A bug fix 
  docs:     Documentation only changes
travi commented 3 years ago

this behavior comes from the list prompt in inquirer. to realistically see a change like you suggest here, you likely need to start with inquirer to enable something similar in the prompt itself.

waynevanson commented 3 years ago

How would setting an option { loop: true } affect the CLI?

I haven't used inquirer but it sounds like it's the least effort to fix my initial problem.