Some background for this refactor:
1. Through a RubyLex instance's lifetime, the context passed to its methods
should be the same.
Given that `Context` is only initialised in `Irb#initialize`,
this should be true.
2. When `RubyLex` is initialised, the context object should be accessible.
This is also true in all 3 of `RubyLex.new`'s invocations.
With the above observations, we should be able to store the context in `RubyLex`
as an instance variable. And doing so will make `RubyLex`'s instance methods
easier to use and maintain.
5c8d3df2df
(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.
* Use colorable: argument as the only coloring control
* Centalize color controling logic at Color.colorable?
There are 2 requirements for coloring output:
1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`
Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like https://github.com/ruby/irb/pull/362
And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
* Add tests for all inspect modes
* Simplify inspectors' coloring logic
* Replace use_colorize? with Color.colorable?
* Remove Context#use_colorize cause it's redundant
1c53023ac4
Instead of accessing the struct as an array, access it via methods. There are other places inside of this file already using this API (for example e0a5c3d2b7/lib/irb/ruby-lex.rb (L829-L830)).
This commit moves all struct array-ish calls to use their method calls instead. It is also ~1.23 faster accessing values via a method instead of as an array according to this microbenchmark:
```ruby
Elem = Struct.new(:pos, :event, :tok, :state, :message) do
def initialize(pos, event, tok, state, message = nil)
super(pos, event, tok, State.new(state), message)
end
# ...
def to_a
a = super
a.pop unless a.empty?
a
end
end
class ElemClass
attr_accessor :pos, :event, :tok, :state, :message
def initialize(pos, event, tok, state, message = nil)
@pos = pos
@event = event
@tok = tok
@state = State.new(state)
@message = message
end
def to_a
if @message
[@pos, @event, @tok, @state, @message]
else
[@pos, @event, @tok, @state]
end
end
end
# stub state class creation for now
class State; def initialize(val); end; end
```
```ruby
Benchmark.ips do |x|
x.report("struct") { struct[1] }
x.report("class ") { from_class.event }
x.compare!
end; nil
```
```
Warming up --------------------------------------
struct 1.624M i/100ms
class 1.958M i/100ms
Calculating -------------------------------------
struct 17.139M (± 2.6%) i/s - 86.077M in 5.025801s
class 21.104M (± 3.4%) i/s - 105.709M in 5.015193s
Comparison:
class : 21103826.3 i/s
struct: 17139201.5 i/s - 1.23x (± 0.00) slower
```
This reverts commit 27dd2867cda5c789efaa5078214ad2fd82adcebf.
This is to fix the test I added.
(I separated commits to test a new behavior of ruby-commit-hook)
fe055d521a
https://github.com/ruby/irb/pull/249 actually slowed down how `code` is
concatenated. The original way of creating `code` is faster.
[before]
user system total real
2.420137 0.005364 2.425501 ( 2.426264)
[after]
user system total real
1.000221 0.007454 1.007675 ( 1.008295)
Theoretically, this implementation might skip lines that don't appear in
Ripper tokens, but this assumes such lines don't impact whether the code
passes compilation or not. At least normal blank lines seem to have an
`on_ignored_nl` token anyway though.
27dd2867cd
