John "banister" Mair describes the following key features of commands
as classes:
1. It enables people to extend them by either subclassing or
monkeypatching.
2. It enables them to provide their own API, so that for example, the
Pry::Command::Edit class could have class methods for people to
configure it.
Please, note that I didn't touch easter eggs commands. I also prettified
some strings (your source code reading experience should vastly improve!).
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
Sometimes I have a failing test, because it can't find Options constant.
Let's help Ruby in its hard job a bit.
Also, reformulate some comments and convert " to ' in some places.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
Fix issue #484 (hist --replay N isn't stored in history).
First, make some small amendments to existing code:
* Make helper methods of "hist" command private;
* What an irony! Amend the name of the duplicated test in
`test_input.rb` ("should not contain duplicated lines" test).
Secondly, resolve the issue. There is one notable moment in current
implementation. Although `hist --replay` calls are being stored in
history, you cannot "replay" entries of this kind (you cannot replay
another call request to replay). Let me show an example:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail
[3] pry(main)> hist --replay 46894
Error: Replay index 46894 points out to another replay call: `hist -r 46675..46677`
[4] pry(main)>
There are two reasons for that.
Reason one or my incompetence
-----------------------------
First of all, I simply failed to implement such behaviour. With current
state of things (that are introduced in this commit), if you do not
raise `Pry::CommandError`, you cannot guarantee that only user's input
is getting stored in history. Here's an example when we get unwanted
entry in history:
[1] pry(main)> hist --show 46894
46894: hist --replay 46675..46677
[2] pry(main)> hist --show 46675..46677
46675: 1+1
46676: a = 100
46677: hist --tail 4
[3] pry(main)> hist --replay 46894
=> 2
=> 100
47021: hist --show 46894
47022: hist --show 46675..46677
47023: hist --replay 46894
47024: hist --replay 46675..46677
[8] pry(main)>
Note that a user typed only `hist --replay 46894`. But the last saved
entry in history is the entry to which user's input, actually, pointed
out (`hist --replay 46675..46677`). So if you press up-arrow key, you
will get not what you expected.
Reason two or "Whoa, whoa, boy! There is a real reason"
-------------------------------------------------------
But the main reason is that you can fall into a loop trap, when both
"hist --replay" calls point to each other. Example of a loop trap:
[31] pry(main)> hist --tail 4
47027: hist --tail
47028: hist --replay 47028
47029: hist --tail
47030: hist --replay 47032
[32] pry(main)> hist -r 47030
# We've just fallen into a loop trap. Let's break out of it.
^C
[416] pry(main)> hist --tail 5
47409: hist --replay 47032
47410: hist --replay 47030
47411: hist --replay 47032
47412: hist --replay 47030
47413: hist --replay 47032
[417] pry(main)>
Note the number of current line (417).
Finally, add some unit tests for this commit.
Signed-off-by: Kyrylo Silin <kyrylosilin@gmail.com>
Kyrylo Silin