Removes Bacon and Mocha
Reasoning explained in this comment: https://github.com/pry/pry/issues/277#issuecomment-51708712
Mostly this went smoothly. There were a few errors that I fixed along
the way, e.g. tests that were failing but for various reasons still
passed. Should have documented them, but didn't think about it until
very near the end. But generaly, I remember 2 reasons this would happen:
`lambda { raise "omg" }.should.raise(RuntimeError, /not-omg/)` will pass
because the second argument is ignored by Bacon. And `1.should == 2`
will return false instead of raising an error when it is not in an it
block (e.g. if stuck in a describe block, that would just return false)
The only one that I felt unsure about was spec/helpers/table_spec.rb
`Pry::Helpers.tablify_or_one_line('head', %w(ing)).should == 'head: ing'`
This is wrong, but was not failing because it was in a describe block
instead of an it block. In reality, it returns `"head: ing\n"`,
I updated the test to reflect this, though I don't know for sure
this is the right thing to do
This will fail on master until https://github.com/pry/pry/pull/1281 is merged.
This makes https://github.com/pry/pry/pull/1278 unnecessary.
PROBLEM DESCRIPTION
===================
The child caches a dup of the parent's hooks,
so it does the correct thing after being accessed the first time.
But the first time it is called, it doesn't return its cached duped value,
it returns the parent's value. This causes 2 bugs:
1. The first hook declared will get "lost", because it is declared
to the parent hooks, not the child's hooks. And after that first
accessing, only the child's hooks will be used
2. The parent's hooks (which are probably the ones from
[the default](0ff6fa61d4/lib/pry/config/default.rb (L35-37)))
are going to get hooks declared on them that shouldn't be
(well, presumably shouldn't be, given the explicit check for
this case and duping to avoid it).
So if another config object was initialized with the same parent,
it would wind up with hooks that it didn't want/expect.
I assume all the other keys work fine because they are value objects,
so if anything wanted to change the value, it would reassign the key
to the config object rather than mutating the returned value.
Mutability *sigh* yallknowwhatimsayin
SOLUTION DESCRIPTION
====================
Return the cached duped child value instead of the parent value.
EXAMPLE
=======
This code from
[the docs](0ff6fa61d4/lib/pry/hooks.rb (L8-11))
will not print "hello", because it's being declared to the parent hook.
```ruby
Pry.config.hooks.add_hook(:before_session, :say_hi) { puts "hello" }
```
This code will, b/c it's being declared to the cached, duped child hook.
```ruby
Pry.config.hooks
Pry.config.hooks.add_hook(:before_session, :say_hi) { puts "hello" }
```
ISSUE IMPACT
============
Fixes#1254
Might fix or have something to do with these issues:
* #1244 Totally thought I got it, but then couldn't reproduce again later
and just don't understand how JRuby builds, so might just be a problem
with how I was trying to reproduce it.
* #1171 Maybe, depending on if Eclipse integrates with it using the
hooks, alternatively, could be the same issue as the one above,
they might both still be broken. Or both fixed and I can't figure out
how to prove it. Dunno.
OTHER THOUGHTS
==============
I'm writing Github flavoured markdown,
but I'm not actually sure if it will get rendered as such in the PR.
Esp since git considers leading octothorpes as comments and not headers,
and removes them...
Guess we'll see... bottoms up, friends!
This is somewhat easier to understand than the current solution,
but does have some downsides: namely it doesn't work for things like
Pry::Hooks.
It is however the only way I've thought of to let setting
Pry.config.color = work in addition to _pry.config.color =.
For now I've added a hack so that hooks work as they did before,
in future we should work out how to fix them so that only the data
for hooks is stored in the config object, not the hooks object itself.
