Removing /\A.+\n/ could have an unexpected impact, depending on how
RubyLex.generate_local_variables_assign_code is implemented. It feels
like a too much assumption and the intention isn't immediately clear,
so I added these changes.
https://github.com/ruby/irb/commit/ccc07a35ce
* Use local_variables for colorize, code_block_open check, nesting_level and assignment_expression check
* Check if expression is an assignment BEFORE evaluating it. evaluate might define new localvars and change result of assignment_expression?
* Add local_variables dependent code test
* pend local variable dependent test on truffleruby
code_block_open is not working on truffleruby
* Always pass context to RubyLex#lex
* Rename local_variable_assign_code generator method name
* Add assignment expression truncate test
* Add Context#local_variables and make generate_local_variables_assign_code more simple
* Update lib/irb/input-method.rb
Co-authored-by: Stan Lo <stan001212@gmail.com>
* Add a comment why assignment expression check should be done before evaluate
https://github.com/ruby/irb/commit/c8b3877281
Co-authored-by: Stan Lo <stan001212@gmail.com>
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
* 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
https://github.com/ruby/irb/commit/1c53023ac4
1. `require` can mislead Ruby to load system irb's files and cause
constant redefined warnings as other code loads the same module/class
from lib folder.
2. Most files already use `require_relative`.
https://github.com/ruby/irb/commit/848d339f2e
Currently `IRB::Color.colorize` and `IRB::Color.colorize_code`
refer `$stdin.tty?` internally.
This patch adds `colorable` keyword option which overrides it.
https://github.com/ruby/irb/commit/402e3f1907
* lib/irb/color.rb (IRB::Color.scan): ignore "incomplete end of
input" error only, to colorize invalid characters, e.g., control
characters, and invalid symbols, as errors.
Let's say we are in progress to write `"foo"`:
```
irb> "fo
```
at this moment, nothing is wrong.
It would be just a normal way to write `"foo"`.
Prior to this commit, the `fo` part was warned because of
5b64d7ac6e. But I think warning such a
normal input is not valuable for users.
However, we'd like to warn `:@1` or `@@1` which is also a syntax error.
Then this commit switches the syntax highlight based on whether the
input text is finished or not. When it's not finished yet, it does not
warn compile_error.
The reason why we were checking lexer state in addition to token was
that we do not want to colorize local variable, method call, etc., while
they share the :on_ident token with a name of method definition which
should be colored as blue.
It means that we're concerned about the lexer state only for :on_ident.
Thus we can skip checking lexer state for non-:on_ident tokens. This
refactoring is based on that idea.
Also, now we manage Ripper's lexer state as Integer (use `|` if you
need to check multiple states). It should be faster than using Array of
Integer because #any? block call is not needed.
Stan Lo
tomoya ishida
Takashi Kokubun
Nobuyoshi Nakada
Nobuhiro IMAI
aycabta
Ary Borenszweig
Koichi Sasada