Add show_cmds command

[st0012]

Specification

• Each command class should specify category and description attributes, like:

      class ShowCmds < Nop
        category "IRB"
        description "List all available commands and their description."
  
        def execute(*args)
          # ...
        end
      end

• show_cmds lists all available commands (group by categories) and their descriptions.

Name Selection

Currently, commands in extend-command.rb aren't named consistently.

• Some are actual commands with irb_ prefix, like irb_ls
• Some are identical with the command, like irb_load
• Some are neither of the above, like irb_pop_workspace

Commands also have different numbers of aliases:

• Some have multiple, like irb_pop_workspace has 5
• Some have just one as the defacto command, like ls
• Some have no aliases and people should use the command name, like irb_load

So in this PR, I try to make the name selection as simple as possible:

1. If the command has no aliases, use its registered command name, like irb_load
2. If the command has aliases, use the first alias as its command name

Result

irb(main):001:0> show_cmds
IRB
  cwws           Show the current workspace.
  chws           Change the current workspace to an object.
  workspaces     Show workspaces.
  pushws         Push an object to the workspace stack.
  popws          Pop a workspace from the workspace stack.
  irb_load       Load a Ruby file.
  irb_require    Require a Ruby file.
  source         Loads a given file in the current session.
  irb            Start a child IRB.
  jobs           List of current sessions.
  fg             Switches to the session of the given number.
  kill           Kills the session with the given number.
  irb_info       Show information about IRB.
  show_cmds      List all available commands and their description.

Debugging
  debug          Start the debugger of debug.gem.
  break          Start the debugger of debug.gem and run its `break` command.
  catch          Start the debugger of debug.gem and run its `catch` command.
  next           Start the debugger of debug.gem and run its `next` command.
  delete         Start the debugger of debug.gem and run its `delete` command.
  step           Start the debugger of debug.gem and run its `step` command.
  continue       Start the debugger of debug.gem and run its `continue` command.
  finish         Start the debugger of debug.gem and run its `finish` command.
  backtrace      Start the debugger of debug.gem and run its `backtrace` command.
  info           Start the debugger of debug.gem and run its `info` command.

Misc
  edit           Open a file with the editor command defined with `ENV["EDITOR"]`.
  measure        `measure` enables the mode to measure processing time. `measure :off` disables it.

Context
  help           Enter the mode to look up RI documents.
  ls             Show methods, constants, and variables. `-g [query]` or `-G [query]` allows you to filter out the output.
  show_source    Show the source code of a given method or constant.
  whereami       Show the source code around binding.irb again.

Future Improvments

• Ideally, show_cmds <cmd> should provide detail usages for individual commands, as well as its aliases.
• show_cmds should be renamed/aliased to help so it matches other tools like pry, debug, and byebug (with the current help renamed to show_doc).
• Styling some texts to improve readability.

[k0kubun]

commands is such a good name that it seems like an official command name to be settled, but I think it's better to just push the direction of #450, given how common it is to use help for that purpose (at least in pry and debug.gem).

WDYT about this?

1. Use a name that is more conservative than commands for now, expecting users to alias it from help for now.
   • I use a variable name commands more often than help, so it'd be annoying for me if commands persists.
2. Add another new alias to the current help, e.g. show_doc and/or show-doc like Pry?
3. After releasing them first, we bump the major version of IRB and replace help with the new command.

[st0012]

I think cmds could work if commands clash with other names more often.

After releasing them first, we bump the major version of IRB and replace help with the new command.

Do you mean:

1. We release cmds and the show_doc alias in, say 1.6.0.
2. We then release 2.0 to rename cmds to help.

If you do, could 2) happen before Ruby 3.2?

[k0kubun]

I think cmds could work if commands clash with other names more often.

I mean something more like an irb_-prefixed name. I've seen people use cmds as a local variable name as well while I personally don't use it. If the final solution is to make it help, I don't think it's a good idea to be aggressive in the naming because you're forced to live with the name conflict or release another breaking change to remove it.

Do you mean:
We release cmds and the show_doc alias in, say 1.6.0.
We then release 2.0 to rename cmds to help.

Yes

If you do, could 2) happen before Ruby 3.2?

The fact that we think it's worth a major version bump in IRB implies that we probably shouldn't make that happen after rc1 that was released yesterday. I'm not sure if it's worth rushing when you could just alias it from help in irbrc.

[st0012]

Here are my thoughts around this:

1. Most IRB users just use the version come with the Ruby. So whichever version we release with Ruby 3.2 will likely be used for a full year, regardless what versions we put out later in the year.
2. Based on 1), if the command name we pick now is going to be used for a year by many users, I'd hope it to be easy to learn as well. So I don't think having an irb_ prefix is ideal.
3. Asking users to alias the command to help manually is also what I'd avoid:
   • It requires creating .irbrc and committing it, which is not very convenient. For example, I need to do that for 5 of my team's projects. ~/.irbrc means inconsistent experience across environments, so I don't usually do that.
   • As a user, I'd wonder why the maintainers don't implement it this way anyway, especially if we already plan to make it happen a year later.
   • I'm NOT trying to push this into 3.2, as I understand the reason behind it. But to users this may not make much sense.
4. If the command name is like irb_cmds and I have to alias it to help myself, I'd just try remembering irb_cmds. And if I don't, I'd just forget about this feature, as it's the only command that can help me in this case 😅

So based on our current plan, I hope we can find something rememberable to users.

I'd open a PR for the show_doc alias soon though. That's a great idea 👍

[k0kubun]

So based on our current plan, I hope we can find something rememberable to users.

What about list_commands or show_commands (or list_cmds or show_cmds) then? They are kind of consistent with newer command names like show_source and show_doc, and less prone to conflicts than commands and cmds.

[st0012]

👍 I've renamed the command to show_cmds.

[k0kubun]

👍 Very nice feature