Skip to content

Introduce something similar to Pry's ls command #29

Closed
#173
Closed
Introduce something similar to Pry's ls command#29
#173

Description

@st0012
st0012
opened on May 25, 2021

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

pry ls

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.

Activity

  1. hsbt commented on May 25, 2021

    @hsbt
    hsbt
    on May 25, 2021
    Member

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

  2. st0012 commented on May 25, 2021

    @st0012
    st0012
    on May 25, 2021
    MemberAuthor

    @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 🤔

  3. st0012 commented on May 25, 2021

    @st0012
    st0012
    on May 25, 2021
    MemberAuthor

    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.

  4. st0012
    closed this as completedon May 25, 2021

  5. st0012 commented on Jul 10, 2021

    @st0012
    st0012
    on Jul 10, 2021
    MemberAuthor

    @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)

  6. ko1 commented on Jul 10, 2021

    @ko1
    ko1
    on Jul 10, 2021
    Collaborator

    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...)
  7. ko1
    reopened this on Jul 10, 2021

  8. ko1 commented on Jul 10, 2021

    @ko1
    ko1
    on Jul 10, 2021
    Collaborator

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

  9. st0012 commented on Jul 11, 2021

    @st0012
    st0012
    on Jul 11, 2021
    MemberAuthor

    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 🤔

  10. ko1 commented on Jul 12, 2021

    @ko1
    ko1
    on Jul 12, 2021
    Collaborator

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

  11. st0012 commented on Jul 13, 2021

    @st0012
    st0012
    on Jul 13, 2021
    MemberAuthor

    I'll open a PR to demonstrate the idea.

  12. st0012 commented on Jul 13, 2021

    @st0012
    st0012
    on Jul 13, 2021
    MemberAuthor

    @ko1 I've implemented it in #172

  13. ko1
    closed this as completedin #173on Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions