(https://github.com/ruby/irb/pull/478)
Given that `show_doc` already supports syntax like `String#gsub`, it
should be able to take it in non-string form too, like `edit` and
`show_source` do. This ensures users can have a consistent syntax on
argument between different commands.
The current `next` pre-command workaround on IRB source stepping
moves the location by 1 extra line. A better way is to make `debug`
skip IRB frames completely, which is what this commit does.
It also fixes the step command's test. The `|` in regexp was not escaped
so it was always incorrectly matched.
(https://github.com/ruby/irb/pull/475)
In the long-term, we want to align with `Pry`, `byebug` and `debug` to
use the `help` command to list all commands, which is what `show_cmds`
currently does. And `show_doc` will be the command to look up Ruby APIs.
By aliasing `show_doc` to the current `help` now, users will have time
to get use to it.
(https://github.com/ruby/irb/pull/473)
* Handle file loading commands' argument error gracefully
Currently, if users don't provide an argument to `source`,
`irb_load`, and `irb_require`, IRB raises `ArgumentError` with full
stacktrace. This is confusing because it looks similar to when IRB has
internal issues. The message also isn't helpful on helping users avoid
the error.
So in this commit, I add a new `CommandArgumentError` for commands to
raise explicitly when users' input doesn't satisfy a command's argument
requirement.
* Gracefully handle `fg` command's argument requirement
This optimization is unsafe because `dest` is allowed to be a custom
object responding to `<<` (e.g. a block wrapped in `ReadAdapter`).
So the receiver can hold onto the passed buffer for as long as it wants.
If it was guaranteed that `ReadAdapter` was the only possible receiver
we could dup the buffer there for mutation safety, but I'm not certain
it's the case so I'd rather err on the safe side.
Ref: https://github.com/shrinerb/shrine/issues/610https://github.com/ruby/net-protocol/commit/7efa16d55d
(https://github.com/ruby/irb/pull/472)
* Lazily load the multi-irb extension
We now have plan to implement a command that prints all commands'
information, which will need to load all command files without actually
running them.
But because the `multi-irb` extension patches IRB's top-level methods,
loading it would cause unintentional side-effects.
So this commit moves related requires into command execution to avoid the problem.
* Make extend_irb_context private
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>