this is a strange and odd case. Pry.prompt is a delegate to Pry.config, as
it has always been. the same delegate was setup on an instance of Pry, but
never used because we define #prompt and #prompt= with our implementation.
the thing that would make the most sense (to me) is to not support Pry.prompt
anymore and recommend the use of Pry.config.prompt instead. a lot of code relies
on Pry.prompt though, so we have to support the delegate to config and implement
custom behavior for the pry instance.
maybe best explained with an example:
[1] pry(main)> Pry.config.hi = "hi"
=> "hi"
[2] pry(main)> _pry_.config.hi
=> "hi"
[3] pry(main)> _pry_.config.x = 1
=> 1
[4] pry(main)> Pry.config.x
=> nil
[5] pry(main)>
'Pry.config' is an instance of Pry::Config::Default. it defines the initial
default configuration values an instance of 'Pry' is going to have. an instance
of 'Pry' uses an instance of Pry::Config who relies on Pry.config as a default
or fallback for keys it cannot find locally.
for example 'Pry.config.color = true' is seen by _all_ pry REPLs who are active
but _pry_.config.color = false is seen only by the REPL session being interacted
with. a number of "config shortcircuts" are still available, for example it is
possible to say `_pry_.input = StringIO.new` or `Pry.input = StringIO.new`. the
shortcuts are maintained for the Pry class and instances of the Pry class through
Pry::Config.shortcuts.
Pry::Config::Convenience adds a method called 'config_shortcuts' which can be used
to setup shortcut access to 'some_obj.config.blah' as 'some_obj.blah'
a lot of tests still fail, so work in progress.
this should help solve #1055.
Robert Gleeson