When creating a command using a custom subclass there may not be a
readily available block. In that case defaulting to the process method
seems reasonable for now.
* blocks can no longer be passed explicitly into commands via command "blah", "desc" |&block| (1.8 compatibility problems)
* blocks must be explicitly enabled for a command with the :takes_block => true option
e.g:
command "hello", "desc" do |&block|
block.call
end
(pry)> hello | do
(pry)* puts "mommy, make me all silver!"
(pry)* end
mommy, make me all silver!
* Blocks are now available by default, turn off explicitly with :takes_block => false
* Example, using &block:
Pry.commands.command "tobina", "desc", :takes_block => true do |&block|
block.call
end
(pry)> tobina { puts "hi" }
hi
(pry)>
* Works with process(&block) too (for create_command)
* Works with do/end blocks and {} blocks, both single and multi-line
* Example, using command_block:
Pry.commands.command "tobina", "desc", :takes_block => true do
command_block.call
end
The CommandSet is responsible for storing Commands, while the Commands
themselves are responsible for all the parsing.
(Before this change, the CommandProcessor used to do both the searching
within the CommandSet's and also the tokenization of command arguments)
