Transform ls's -g/-G option to keyword args

[k0kubun]

Leveraging the transform_args capability in #430, this PR introduces -g / -G option to ls to pass grep option.

irb(main)[01:0]> erb = ERB.new('src')
=>
#<ERB:0x00007f009bf992f8
...
irb(main)[02:0]> ls erb
ERB#methods:
  def_class  def_method   def_module  encoding  filename  filename=  lineno  lineno=  location=  make_compiler  result  result_with_hash
  run        set_eoutvar  src
instance variables: @_init  @encoding  @filename  @frozen_string  @lineno  @src
=> nil
irb(main)[03:0]> ls erb -G result
ERB#methods: result  result_with_hash
=> nil

[st0012]

Looks like a very useful feature 👍

A few questions:

• Why is --grep's short version -G? I feel -g fits convention better (like -v for --version) and is easier to type.
  • I know -G comes from Pry, so I have the same question for it too 😅
• Can we limit the supported cases to just 2 or even 1? I'll reduce the maintenance effort and make introducing new flags easier.
  • Specifically, I'd expect flags and args have fixed positions.
  • <cmd> <flag> <arg> matches my general command line experience better.
  • In debug, commands don't have flags but have options, like break Foo#bar if: <condition>. Do we want to lean toward debug more or make it closer to Pry 🤔

[k0kubun]

Why is --grep's short version -G? I feel -g fits convention better (like -v for --version) and is easier to type.
I know -G comes from Pry, so I have the same question for

Because Pry also has --globals/-g. I think it's not a bad idea to reserve -g for that instead of taking the risk to end up with the other way in IRB while I still don't intend to work on --globals/-g support in this PR.

matches my general command line experience better.

The workflow is usually,

1. Input $ ls erb. See too many methods.
2. C-p to resurrect ls erb. Start typing -G result, which naturally makes it ls erb -G result.

So for this use case, I think <cmd> <arg> <flag> is a better experience. I'm okay to only leave that support, but once I come up with a use case that needs the other case after using that version, I would just come here again and file a patch to support that.

Do you want to support only <cmd> <arg> <flag> first?

[st0012]

I think -g is more like another command than an option of the ls command. Like it can't even be used with an object

[7] pry(main)> ls Object -g
Error: -g does not make sense with a specified Object

I'm incline to not supporting ls --globals and has something like globals for that feature instead. With that in mind, I don't want to reserve -g for it, which makes more sense for --grep IMO.

Do you want to support only first?

Yeah your example is very convincing. That's go with that format first 👍

[k0kubun]

With that in mind, I don't want to reserve -g for it, which makes more sense for --grep IMO.

What about accepting both -g and -G then? With the amount of times I've used ls -G, it feels nearly impossible for my fingers to just forget typing -G on ls. If we support only -g, I'd be so stressed out that I'll just monkey-patch this again. I will likely not be a user of -g myself until the world uninstalls Pry everywhere. Given that we pretend to be Pry-compatible in some ways, I think it's a useful feature to be somewhat compatible with Pry.

[st0012]

Yeah that makes sense.
I also wonder if people actually type --grep instead of just -G. Perhaps we can add -g, -G for now, and --grep when requested?

[k0kubun]

I also wonder if people actually type --grep instead of just -G. Perhaps we can add -g, -G for now, and --grep when requested?

works for me 👍 9e53571

I think this PR is ready for your review again.

[st0012]

👍
There seems to be a flaky test failed in a truffleruby suite.