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 brigter 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?

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

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

Uh oh!

st0012 commented Mar 26, 2026

Uh oh!

shugo commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tompng Mar 25, 2026 •

edited

Loading