Highlight the method name in method calls by shugo · Pull Request #1189 · ruby/irb

shugo · 2026-03-25T02:41:15Z

It's useful to differentiate method calls from local variable references.

Method calls in `binding.irb` may be colorized.

This fix prevents struct members from being colorized.

tompng · 2026-03-25T06:03:42Z

lib/irb/color.rb

          super
        end

+        def visit_call_node(node)


Writer methods are also colored blue, but Writer methods with operators are not colored.

# "foo" is colored a.foo = 1 # "foo" is not colored a.foo += 1 a.foo &&= 1 a.foo ||= 1

So I think we can also add visitor methods for CallAndWriteNode CallOperatorWriteNode CallOrWriteNode.

I've fixed it in 66933a9.

tompng · 2026-03-25T06:13:23Z

lib/irb/color.rb


+        def visit_call_node(node)
+          if @colorize_call
+            if node.call_operator_loc.nil? && OPERATORS.include?(node.name)


For a[:key] a[:key] = 2, message_loc contains index part and wrongly colored blue, so we need to exclude :[] and :[]= when call_operator_loc is nil.

When call_operator_loc is present(a.[]=(1, 2)) message_loc is already colored correctly.

I've fixed it in 8643c13.

tompng · 2026-03-25T06:30:34Z

lib/irb/color.rb

+            if node.call_operator_loc.nil? && OPERATORS.include?(node.name)
+              # Operators should not be highlighted
+            else
+              dispatch node.message_loc, :message_name


Current colorization is:

Array(1) Kernel::Array(1) are definitely a method call, but I think it might be better colored as constant.

In an explicit method call case Kernel.Array(), Kernel&.Array(), it may be better colored as method_name.
What do you think?

Agreed.

I've fixed it in 0b398c3.

Colorize method name `foo` in the following code: ``` a.foo += 1 a.foo &&= 1 a.foo ||= 1 ```

Copilot

Pull request overview

This PR updates IRB’s syntax colorization to visually distinguish method calls by applying a dedicated style to method/message names during AST traversal.

Changes:

Add a new message_name token style and colorize method/message names for Prism call nodes in IRB::Color.colorize_code.
Add a colorize_call: keyword to enable/disable call highlighting (disabled for IRB::ColorPrinter output).
Update IRB colorization tests and adjust an integration-test regex to tolerate ANSI color sequences around binding.irb.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
`lib/irb/color.rb`	Introduces `message_name` styling and Prism visitor logic to highlight method/message names; adds `colorize_call:` option.
`lib/irb/color_printer.rb`	Disables call highlighting when pretty-printing fragments to avoid coloring method-like strings in printer output.
`test/irb/test_color.rb`	Updates/expands expectations to reflect method-name highlighting behavior.
`test/irb/helper.rb`	Updates breakpoint detection regex to match `binding.irb` even when colored.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-25T10:18:35Z

lib/irb/color.rb

+            if node.call_operator_loc.nil? && OPERATORS.include?(node.name)
+              # Operators should not be colored as method call
+            elsif (node.call_operator_loc.nil? || node.call_operator_loc.slice == "::") &&
+                /\A\p{Upper}/.match?(node.name)


colorize_call calls Regexp#match? with node.name. In Prism, CallNode#name is commonly a Symbol (e.g., :[]=, :+), and passing a Symbol to match? raises TypeError. Consider normalizing once (e.g., name_str = node.name.to_s and name_sym = node.name.is_a?(Symbol) ? node.name : node.name.to_sym) and using name_sym for OPERATORS.include? and name_str for the uppercase check.

Suggested change

if node.call_operator_loc.nil? && OPERATORS.include?(node.name)

# Operators should not be colored as method call

elsif (node.call_operator_loc.nil? || node.call_operator_loc.slice == "::") &&

/\A\p{Upper}/.match?(node.name)

name = node.name

name_sym = name.is_a?(Symbol) ? name : name.to_sym

name_str = name.to_s

if node.call_operator_loc.nil? && OPERATORS.include?(name_sym)

# Operators should not be colored as method call

elsif (node.call_operator_loc.nil? || node.call_operator_loc.slice == "::") &&

/\A\p{Upper}/.match?(name_str)

Besides that, CallOperatorWriteNode seems not to have the name method. I'll fix it.

Fixed in db9cd4c.

Regexp#match? accepts symbols, so there's no need to call to_s.

shugo · 2026-03-26T07:15:13Z

lib/irb/color.rb

+        def visit_call_operator_write_node(node)
+          dispatch node.message_loc, :message_name if @colorize_call
+          super
+        end
+
+        def visit_call_and_write_node(node)
+          dispatch node.message_loc, :message_name if @colorize_call
+          super
+        end
+
+        def visit_call_or_write_node(node)
+          dispatch node.message_loc, :message_name if @colorize_call
+          super
+        end


I didn't use alias to keep super dispatching to the right visit_ method.
However, it seems that NestingParser uses alias, relying on the fact that the current implementation of all visit_* in Prism::Visitor is the same.

st0012 · 2026-03-26T12:44:55Z

I like having colors to distinguish method calls and local variables, but picking the right color is pretty tricky, especially for tokens as common as method calls.

Ideally, with this change we want to have:

The same color between method name in definition (currently yellow) and method name in call (introduced as blue here)
Different colors between method calls and common adjacent tokens. For example:
```
a = 1
Foo.bar(a)
```
Foo, bar, and a should each have a distinctive color. Currently in the PR both Foo and bar are blue
If we combine both 1 and 2, we should color method calls as yellow. Though it kinda hurts my eye with the light yellow my terminals default to:

(If we can dim it a bit it would be perfect 😢)

So TL;DR - I think yellow would be a better color for both consistency and visual distinction.

shugo · 2026-03-26T23:35:27Z

@st0012 Thanks for your feed back.

Ideally, with this change we want to have:

The same color between method name in definition (currently yellow) and method name in call (introduced as blue here)

The current color of method name in definition is blue, isn't it?

irb/lib/irb/color.rb

Line 105 in 8a1129d

method_name: [BLUE, BOLD],

(On my terminal, WezTerm, characters with bold attribute are brighter than the ones without bold attr.)

I chose blue because it's used for method name in definition, but I have no strong opinion.

Different colors between method calls and common adjacent tokens. For example:

It might be good if method name name in definition were highlighted with a different color such as magenta.

st0012 · 2026-03-26T23:42:02Z

Oh wait I changed the color different times for testing and forgot to change back, sorry 🤦‍♂️

So now 1 is satisfied. I think it'd be great if we can make 2 happen too. WDYT changing constants to another color?

shugo · 2026-03-27T04:23:19Z

So now 1 is satisfied. I think it'd be great if we can make 2 happen too. WDYT changing constants to another color?

It sounds good to me.

I noticed that ENV is specifically highlighted in cyan.
How about magenta for other constants?

st0012 · 2026-03-27T17:22:06Z

Magenta:

Yellow:

Cyan:

Not a fan of green + magenta when defining a class, but yellow is too bright and cyan is too close to blue. So yeah I'd go with magenta for now and we can later implement theme feature to support more color combinations.

@tompng Any preference?

eregon · 2026-03-27T18:02:43Z

IMO Cyan looks good, it's close to blue but easily differentiable still.

tompng · 2026-03-27T19:44:58Z

yellow is too bright

Agree.
I like magenta. I also like cyan. they both looks nice to me.
For ENV, I don't think ENV is a special constant compared to ARGF, ARGV, STDIN, STDOUT, STDERR.
Maybe we can make all constants the same color with bold and underline.

eregon · 2026-03-27T20:06:58Z

In the Cyan screenshot, nil is underlined, but nil isn't a constant it's a keyword so probably it shouldn't be underlined?

Magenta looks OK to me too, and might be better to differentiate keywords & constants.

For ENV, I don't think ENV is a special constant compared to ARGF, ARGV, STDIN, STDOUT, STDERR.
Maybe we can make all constants the same color with bold and underline.

👍

st0012 · 2026-03-27T21:23:46Z

I'm also fine with cyan if that's what people choose 👍

shugo · 2026-03-27T23:56:48Z

Thanks for your comments.

Green + magenta looks fine on my terminal, but seem not look good on Stan's, so I'd like to choose cyan for method names and highlight ENV the same as other constants.

It was not used to keep `super` dispatch to the right `visit_` method. However, it seems that `NestingParser` uses `alias`, relying on the fact that the current implementation of all `visit_*` in `Prism::Visitor` is the same.

shugo · 2026-03-30T08:28:42Z

Green + magenta looks fine on my terminal, but seem not look good on Stan's, so I'd like to choose cyan for method names and highlight ENV the same as other constants.

I've addressed these issues and have supported alias in
https://github.com/ruby/irb/pull/1189/changes/db9cd4cab32198435d60d1911a960218b8bf0cac..2c7df4dd2488ff55e7fa74b2c85d8d374e291392

st0012 · 2026-03-30T11:23:45Z

lib/irb/color_printer.rb

        super(@colorize ? Color.colorize(str, [:GREEN]) : str, width)
      else
-        super(@colorize ? Color.colorize_code(str, ignore_error: true) : str, width)
+        super(@colorize ? Color.colorize_code(str, ignore_error: true, colorize_call: false) : str, width)


Why do we not want to colorize call in this case?

The above code was introduced to fix the following failure of the debug compatibility test:

https://github.com/ruby/irb/actions/runs/23522320220/job/68468010147

Hmm. I don't like that we update IRB lib code to workaround a test.

I'd prefer:

Ship without this workaround

Propose test changes to debug

Let CI fail for a few days until 2 is merged

An alternative could be to disable this test until 2 is merged.

@tompng WDYT?

I'm not sure if it's correct to highlight member names as method names in the Struct inspect output.

Furthermore, the results might differ in environments where variables with the same names as the members are defined.

Furthermore, the results might differ in environments where variables with the same names as the members are defined.

This might be an overthought, as no local variables are specified here.

shugo added 3 commits March 25, 2026 11:34

Highlight the method name in method calls

061f494

It's useful to differentiate method calls from local variable references.

Fix the timeout of test_direct_debug_session_loads_history

9c9f1f6

Method calls in `binding.irb` may be colorized.

ColorPrinter should not colorize method calls

d6369b9

This fix prevents struct members from being colorized.

tompng reviewed Mar 25, 2026

View reviewed changes

shugo added 3 commits March 25, 2026 17:22

Colorize writer methods

66933a9

Colorize method name `foo` in the following code: ``` a.foo += 1 a.foo &&= 1 a.foo ||= 1 ```

Do not colorize index operators

8643c13

Do not colorize constant-like method names as method calls

0b398c3

shugo requested a review from Copilot March 25, 2026 10:13

Copilot started reviewing on behalf of shugo March 25, 2026 10:13 View session

Copilot AI reviewed Mar 25, 2026

View reviewed changes

Method name check is not necessary for writer methods

db9cd4c

shugo commented Mar 26, 2026

View reviewed changes

st0012 added the enhancement New feature or request label Mar 27, 2026

shugo added 4 commits March 28, 2026 10:49

Use cyan for method names to differentiate from constants

dd0469a

Use alias for writer methods to reduce code duplication

d9ef6d9

It was not used to keep `super` dispatch to the right `visit_` method. However, it seems that `NestingParser` uses `alias`, relying on the fact that the current implementation of all `visit_*` in `Prism::Visitor` is the same.

Highlight method names in alias

89f5bae

Highlight ENV the same as other constants

2c7df4d

st0012 reviewed Mar 30, 2026

View reviewed changes

Conversation

shugo commented Mar 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tompng Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

st0012 commented Mar 26, 2026

Uh oh!

shugo commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

st0012 commented Mar 26, 2026

Uh oh!

shugo commented Mar 27, 2026

Uh oh!

st0012 commented Mar 27, 2026

Uh oh!

eregon commented Mar 27, 2026

Uh oh!

tompng commented Mar 27, 2026

Uh oh!

eregon commented Mar 27, 2026

Uh oh!

st0012 commented Mar 27, 2026

Uh oh!

shugo commented Mar 27, 2026

Uh oh!

shugo commented Mar 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

tompng Mar 25, 2026 •

edited

Loading

shugo commented Mar 26, 2026 •

edited

Loading