Add helper aliases

[bkuhlmann]

Description

Hello. 👋 With the new extension support in IRB 1.13.0, would it be possible to add IRB.conf[:HELPER_ALIASES] like we have for command aliases? I ask, because the HELPER_ALIASES key doesn't exist and if you try to add an alias for a helper within the existing command aliases, you'll get an stack dump. Example:

require "irb/kit"

IRB::Kit.register_helpers :clip
IRB.conf[:COMMAND_ALIASES].merge! cp: :clip
cp "Test"

# irb-1.13.1/lib/irb/context.rb:603:in `evaluate': undefined method `execute' for nil (NoMethodError)
# statement.command_class.execute(self, statement.arg)
#                        ^^^^^^^^

💡 IRB Kit is a new gem I'm using to load custom helpers within IRB.

Alternatively, if the above is not desired, it might not make sense to have a key for command and helper aliases since I'm not sure how you'd differentiate between the two (at least not easily). So maybe you should be able to alias both commands and helpers via a single key (i.e. simply: ALIASES)?

Result of irb_info

Ruby version: 3.3.1
IRB version: irb 1.13.1 (2024-05-05)
InputMethod: RelineInputMethod with Reline 0.5.7 and /Users/bkuhlmann/.inputrc
Completion: Autocomplete, ReplTypeCompletor: 0.1.6, Prism: 0.29.0, RBS: 3.4.4
.irbrc paths: /Users/bkuhlmann/.config/irb/irbrc
RUBY_PLATFORM: arm64-darwin23.4.0
LANG env: en_US.UTF-8
East Asian Ambiguous Width: 1

Terminal Emulator

iTerm2

Setting Files

~/.config/irb/irbrc (via XDG)

[st0012]

I currently don't plan to support helper aliases because unlike commands, their aliases need to be valid Ruby code. This means that we need to also validate the alias users use, which is complexity I don't want to add without seeing clear benefit.

Looking at your gem's "helpers", I think almost all of them should actually be commands? If their use cases are displaying information or performing tasks (copy & pasting), not directly interacting with other parts of the "app", then they should be commands, not helpers.

FWIW, I think certain helpers actually overlap with IRB's builtin commands:

• show_source already does what csource and msource do:

  # help show_source
  Usage: show_source [target] [-s]
  
    -s  Show the super method. You can stack it like `-ss` to show the super of the super, etc.
  
  Examples:
  
    show_source Foo
    show_source Foo#bar
    show_source Foo#bar -s
    show_source Foo.baz
    show_source Foo::BAR
  

• ls Module -g pattern sort of does what search does, with less information so maybe not a direct replacement.

[bkuhlmann]

I currently don't plan to support helper aliases

Thanks, that's good to know and, yes, no need to add complexity if there isn't a need for aliasing helpers.

they should be commands, not helpers.

Thanks. So this would be an opportunity to clarify in the documentation. I found this confusing so opted to use helpers instead of commands because they seemed simpler and more lightweight to implement. I've taken note of this and will fold your suggestions into a future version release.

show_source already does what csource and msource do.

This is partially correct, I agree, but they serve a different purpose with the following benefit:

• I get an absolute path with line number so I can immediately CONTROL + <click> (think: iTerm2) to jump into the source code via my editor immediately. Sometimes it's nice to stay in IRB but often I really want to be browsing source in my IDE.

ls Module -g pattern sort of does what search does.

Yeah, this is similar to what I was saying about csource and msource. There are similarities but I get the following benefit:

• Access to the method signature (specifically, the parameters).

---

Based on this discussion, I'm going close this since there is no further action. The rest I can follow up with on my end. Thanks for the feedback!

[st0012]

I found this confusing so opted to use helpers instead of commands because they seemed simpler and more lightweight to implement.

Do you think expanding the first paragraph with example use cases for each type will help? For example:

- Use helper method if the operation:
  - Is meant to return a Ruby object that interacts with the application, like `my_helper.call_other_methods_on_it`
- Use command if the operation:
  - Is a utility that perform non-Ruby related tasks, like copying output from IRB
  - Displays information, like listing route in your Rails applications
  - ....

If you don't know what to pick, go with commands first.

I get an absolute path with line number

show_source also displays file path and line number, so we can still do that:

ruby-lsp(main):002> show_source RubyLsp

From: /Users/hung-wulo/src/github.com/Shopify/ruby-lsp/lib/ruby-lsp.rb:4

module RubyLsp
  VERSION = File.read(File.expand_path("../VERSION", __dir__)).strip
end

Access to the method signature (specifically, the parameters).

Hmm, I think maybe it's worth adding a flag to ls command for including parameters 🤔

[bkuhlmann]

Do you think expanding the first paragraph with example use cases for each type will help?

Yes! I also like the last line to drive home the point.

show_source also displays file path and line number.

Hmm, I might drop the duplication on my side, because I was able to confirm iTerm still honors the the file path and line number by opening appropriately in my IDE. Thanks.

I think maybe it's worth adding a flag to ls command for including parameters

Yeah, that would be handy. Either like how I do it (using object.methods.grep):

search IRB, "start"
# [
#   start(*ap_path) IRB.start (ap_path=..
# ]

..or via Method#parameters:

IRB.method(:start).parameters
# [
#   [
#     :opt,
#     :ap_path
#   ]
# ]

I have Amazing Print wired into my IRB config so gives me a structured dump but using collapsed/single line output makes sense too.

[st0012]

Yes! I also like the last line to drive home the point.

Thanks for the feedback. I added #965 for it 🙂

[bkuhlmann]

Awesome, thanks! 🙇