Introduce something similar to Pry's ls command

[st0012]

The ls command is one of my favorites when using Pry. It gives users a quick overview on the objects with information like:

• Methods & their defined classes
• Constants
• Instance variables
• Locals

Usage

[4] pry(main)> ls -h
Usage: ls [-m|-M|-p|-pM] [-q|-v] [-c|-i] [Object]
       ls [-g] [-l]

ls shows you which methods, constants and variables are accessible to Pry. By
default it shows you the local variables defined in the current shell, and any
public methods or instance variables defined on the current object.

# .....

Also check out `find-method` command (run `help find-method`).

    -m, --methods               Show public methods defined on the Object
    -M, --instance-methods      Show public methods defined in a Module or Class
    -p, --ppp                   Show public, protected (in yellow) and private (in green) methods
    -q, --quiet                 Show only methods defined on object.singleton_class and object.class
    -v, --verbose               Show methods and constants on all super-classes (ignores Pry.config.ls.ceiling)
    -g, --globals               Show global variables, including those builtin to Ruby (in cyan)
    -l, --locals                Show hash of local vars, sorted by descending size
    -c, --constants             Show constants, highlighting classes (in blue), and exceptions (in purple).
                                Constants that are pending autoload? are also shown (in yellow)
    -i, --ivars                 Show instance variables (in blue) and class variables (in bright blue)
    -G, --grep                  Filter output by regular expression
    -d, --dconstants            Show deprecated constants
    -h, --help                  Show this message.

Implementation Options

Add a new command

If we go for this, we should come up with a new name though. Because this project already has the l[ist] command for listing source code, naming this command ls could be confusing.

Enhance the info command

The info command is designed to show information about the current frame. So it doesn't exactly match what Pry's ls does. But if we can add the current functionality to a info f[rame] subcommand, info can be more generic and perform something like the ls does.

[hsbt]

FYI: It's already implemented on IRB at ruby/irb@19b6c20

[st0012]

@hsbt wow that looks awesome 🎉 I guess the question now becomes: is there a way we can use it from the debug session without entering irb 🤔

[st0012]

I think this can wait for the decision on whether to integrate the debugger with irb, so we can make a better call on the implementation.

[st0012]

@ko1 It looks like irb integration won't come anytime soon. Do you think we can support out own version of ls too? Currently, it takes:

pp Rails::Application.instance_methods(false)
pp Rails::Application.methods(false)
pp Rails.application.instance_variables

to list similar information to the ls command. And the output format is not as readable.

The implementation would be similar to irb's, which is well-decoupled from the irb core. (Perhaps someday we can make something that works for both ends).

(this isn't a release blocker for 1.0)

[ko1]

Yes, we can implement it differently.
Actually, I planned to introduce this feature with info <expr> (i <expr>) command, but I removed it because other debuggers like gdb, byebug has sub-command.

I'm not sure we should introduce same command of pry's ls, especially, -x type command notation.

• 👍 I agree it is familiar with many Rubyists.
• ls is also known as list files command in shell (maybe because I'm not a Rubyist using pry frequently :p ). People should use this command frequently, and ls is enough short.
• 👎 It seems tough to parse this style 😢 (for example, we need to support both ls obj -l, ls -l obj) (ah, -l of pry's ls is not long option...)

[ko1]

If we can call irb and execute any command string, we can implement it simply call ls <expr> and quit irb.

[st0012]

ls is also known as list files command in shell (maybe because I'm not a Rubyist using pry frequently :p ). People should use this command frequently, and ls is enough short.

since irb also has implemented ls, I think the confusion should be minimum.

👎 It seems tough to parse this style 😢 (for example, we need to support both ls obj -l, ls -l obj) (ah, -l of pry's ls is not long option...)

Personally, I rarely use any options. It looks like irb's ls doesn't accept options either. So I don't think options are necessary for debugger's ls. This should make implementation a lot simpler.

If we can call irb and execute any command string, we can implement it simply call ls and quit irb.

Perhaps we can invoke irb without entering an irb session in this way (copied from irb's test case):

input = "ls"
IRB.init_config(nil)
workspace = IRB::WorkSpace.new(self)
IRB.conf[:VERBOSE] = false
irb = IRB::Irb.new(workspace, input)
IRB.conf[:MAIN_CONTEXT] = irb.context
irb.context.return_format = "=> %s\n"
irb.eval_input

A downside is that it relies on irb's underlying components. I'm not sure how stable they are 🤔

[ko1]

Thank you for the survey, but it is hard to understand correctly...

[st0012]

I'll open a PR to demonstrate the idea.

[st0012]

@ko1 I've implemented it in #172