Introduce cd command

[st0012]

It's essentially a combination of pushws and popws commands that are easier to use.

Help message:

Usage: cd ([target]|..)

IRB uses a stack of workspaces to keep track of context(s), with `pushws` and `popws` commands to manipulate the stack.
The `cd` command is an attempt to simplify the operation and will be subject to change.

When given:
- an object, cd will use that object as the new context by pushing it onto the workspace stack.
- "..", cd will leave the current context by popping the top workspace off the stack.
- no arguments, cd will move to the top workspace on the stack by popping off all workspaces.

Examples:

  cd Foo
  cd Foo.new
  cd @ivar
  cd ..
  cd

Please note that it's not a replica of Pry's cd command as it doesn't support the / argument, nor complicated navigation syntax.

[kmcphillips]

I love this. Anytime I try to teach someone they can use binding.irb without a gem depencency to pry, I have to say "It's like Pry but..." and this removes one of the things on that list.

[kmcphillips]

How about the cd - case? As in, go to the previous but also push the current back on the stack.

[st0012]

Unlike the rest of the PR that's built on top of existing features, this requires adding new internal API and will not work nicely with other workspace commands like pushws...etc. I implemented it anyway but I'll let other maintainers decide if it's worth the extra complexity.

[st0012]

To support this, we need a way to remember popped workspaces too. And because commands are not memoized, we can't use ivars here. So I needed to add a new previous_workspace attribute to Context just for this feature. Additionally, it will not work with other commands like pushws or chws without adding further complexities.

While I understand its use cases, I personally don't use it. So either keeping or dropping it is fine for me. Thoughts? @ruby/irb-reline

[tompng]

I think it's worth adding, or maybe we can add it later. Not particular about keeping or dropping it at the first step.

Since cd has a stack that represents directory-like model, I think cd - should restore the whole stack, not just the current workspace.

cd 1  # 1
cd 2  # 1/2
cd 3  # 1/2/3
cd .. # 1/2
cd -  # 1/2/3
cd    # main
cd -  # 1/2/3
cd .. # 1/2

And we need to consider irb_context.previous_workspace==nil case.

$ irb
irb(main):001> cd -

[st0012]

That's a good point. I'll update my implementation 👍

[brandondrew]

- "..", cd will leave the current context, moving back to the previous context.

I believe this is incorrect, based on both the assumption that this works similarly to cd .. in a shell, and based on the code shown above (in a previous comment), which shows it 'popping' contexts (which normally means moving up a level, unless the 'popping' metaphor is also very different in irb.) I've copied that code here:

        when ".."
          irb_context.pop_workspace

Popping does not necessarily take you to the previous workspace. You could be where you are because of using cd -, in which case the next level up might not be the previous workspace.

[alpaca-tc]

Thanks for the great PR 💛
I hope this PR will be merged because I also used the cd command in my .irbrc.

Currently, this PR doesn't support cd ../.. like pry.
I would like this feature. Do you have any plans to add it in the future?

[st0012]

Popping does not necessarily take you to the previous workspace. You could be where you are because of using cd -, in which case the next level up might not be the previous workspace.

It'll be the previous workspace on the same workspace stack. In this context, previous means the previous value that's been added to the stack (array). I know it's not perfectly accurate, but I can't think of better description for it and I'm open to better ideas 🙂

I would like this feature. Do you have any plans to add it in the future?

Unfortunately I don't plan to introduce nested syntax atm, such as cd @x/@y like Pry does. In the similar sense, I won't introduce multi-level exits yet.

[st0012]

I couldn't 100% replicate Prys' cd - behaviour without making huge changes, which is against my goal to build a nicer interface based on the current implementation. Even if I were allowed to cut a few corners and deliver a simpler version of it, I wouldn't know where to cut and what to keep as I personally am not a user 😅
So I decided to drop it from the current PR and ship what we have first. If you really want to see cd -, please open an issue and describe the desire behaviour in details. Thanks 🙂