Feature #21960: Improve #backtrace to not confuse terminals

• Status: Open
• Assignee: -
• Target version: -

[svoop (Sven Schwyn)]

The #backtrace of exceptions are currently printed like so:

/path/to/whatever.rb:8:in `/'
/path/to/whatever.rb:8:in `show'
(...)

Most terminals recognize /path/to/whatever.rb:8 as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case /path/to/whatever.rb:8:in. This is then used as an argument to open (on macOS) which will not work due to the :in part.

There are two ways to improve this:

Replace the colon with a space

Given the existence of #backtrace_locations which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the #backtrace to look like this:

/path/to/whatever.rb:8 in `/'
/path/to/whatever.rb:8 in `show'
(...)                ^^^
                     space instead of colon

Add OCS 8 sequences

OCS 8 are the <a> tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument.

[byroot (Jean Boussier)]

• Related to Feature #14145: Proposal: Better Method#inspect added

[byroot (Jean Boussier)]

• Tracker changed from Misc to Feature

I believe this would be a good change, we did make a similar decision to use spaces over other symbols in [Feature #14145], so that it's easier to select.

This however has some small backward compatibly consequences, as code parsing backtraces with regexps isn't that rare.

That being said, most of the time, this sort of code would be much better to use backtrace_locations instead, one downside however is that in rare cases, some exceptions do have a #backtrace but no #backtrace_locations.

[Eregon (Benoit Daloze)]

+1, also I think it reads better with a space.

Re #14145 the motivation to use a space was also to be clickable: https://bugs.ruby-lang.org/issues/14145#note-25

FWIW your example in the description is using older backtrace, they look like this since 3.4:

$ ruby -ve 'tap { raise }'
ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux]
-e:1:in 'block in <main>': unhandled exception
	from -e:1:in 'Kernel#tap'
	from -e:1:in '<main>'

[svoop (Sven Schwyn)]

@Eregon (Benoit Daloze) You're right, my bad, I happened to be on a project which still runs on Ruby 3.1. However, the colon is present on Ruby 4.0 as well:

path/to/test.rb:1:in 'Integer#/': divided by 0 (ZeroDivisionError)
        from path/to/test.rb:1:in '<main>'

[vo.x (Vit Ondruch)]

This however has some small backward compatibly consequences, as code parsing backtraces with regexps isn't that rare.

That being said, most of the time, this sort of code would be much better to use backtrace_locations instead

This is typically not the case for test suites, unfortunately

[byroot (Jean Boussier)]

This is typically not the case for test suites

I'm not 100% sure I understand what you mean.

But yes, this change would certainly require to update a bunch of test there and there, just like when we changed labels to use single quotes intead of backticks.

[byroot (Jean Boussier)]

• Related to Feature #16495: Inconsistent quotes in error messages added

[vo.x (Vit Ondruch)]

byroot (Jean Boussier) wrote in #note-6:

I'm not 100% sure I understand what you mean.

When the backticks were changed, I have seen more broken test suites then the actual code. And the test suites typically checks error text output, probably by matching plain text or some RegExp. And I think that is very reasonable method for such test. Anything beyond that might be over engineered and prone to different issues.

[svoop (Sven Schwyn)]

From my POV, some failing tests which are easy enough to find and fix are no deal breaker though, albeit other people's mileage may vary. Problematic is (untested) code failing in production which is not very likely in this case and would point to a bigger code smell at large.

[mame (Yusuke Endoh)]

Has the reporter confirmed that this change would actually make backtraces clickable in Ghostty? I suspect it would not.

I found the relevant Ghostty discussion (I'm surprised it wasn't linked in the description):
https://github.com/ghostty-org/ghostty/discussions/11378

Ghostty passes matched strings verbatim to open in macOS. It has no file:line parser. So even with the space change, the match would stop at /path/to/file.rb:35, and open -t /path/to/file.rb:35 would still fail -- just like src/example/module.ts:42 fails in the discussion above.

Ghostty has a planned link config for custom matchers (https://ghostty.org/docs/config/reference#link), but it's marked "TODO: This can't currently be set!" A Ghostty collaborator also suggests tools should emit OSC 8 hyperlinks instead. Either way, changing the colon to a space in Ruby would not help.

I have to be blunt: this proposal asks us to break backward compatibility based on an unverified assumption. No one has demonstrated that it actually fixes anything. All pain, no gain. I strongly oppose making this change until Ghostty's file:line story is settled and someone can show a concrete improvement.

[byroot (Jean Boussier)]

To be clear, my (limited) support of the change has nothing to do with Ghosty (never used it, no idea what its capabilities are), and not to support printing links. I only support replacing : with a space.

As mentioned in https://bugs.ruby-lang.org/issues/14145#note-25, several terminals when double clicking on text will extend the selection until they reach spaces, but even without that feature (my terminal doesn't have it) it's much easier to read and select with a click+drag.

So I do believe it's marginally better than the current format. Whether the benefits outweigh the cost of the churn, is however very debatable.

[byroot (Jean Boussier)]

• Related to Feature #16101: Proc#to_s returns "... file:line" instead of "...@file:line" added

[byroot (Jean Boussier)]

(my terminal doesn't have it)

Actually after a quick search, it does have it, in Terminal.app (macOS default terminal), using cmd+shift+double-click.

path/to/file.rb:24:in `some_method`
path/to/file.rb:24 in `some_method`

In the above example the feature selects path/to/file.rb:24:in and path/to/file.rb:24 respectively.

[svoop (Sven Schwyn)]

You're right about open failing on line numbers, @mame (Yusuke Endoh), sorry for the confusion. I was experimenting with a wrapper for open higher up in the $PATH and accidentally hit it – which looked as if open handled line numbers correctly.

Ghostty is just the reason I tripped over the colon, by no means a good reason for such a change. However, as @byroot (Jean Boussier) mentioned, there are likely more situations where the second colon causes hickups. For instance, Zed does support a second colon:

Arguments:
  [PATHS_WITH_POSITION]...
          The paths to open in Zed (space-separated).
          Use `path:line:column` syntax to open a file at the given line and column.

No idea what Zed makes of :in for a column, but I'd be happy to investigate further if there's any interest. Please just close this issue otherwise.

[Eregon (Benoit Daloze)]

For context, https://bugs.ruby-lang.org/issues/14145#note-25 was about what the terminal selects when double-clicking on the path.

In ptyxis and Gnome Terminal (commonly used terminals on Linux), this is the results:

path/to/test.rb:1:in ... # selects `path/to/test.rb` (good)
path/to/test.rb:1 in ... # selects `path/to/test.rb` (good)
Integer#times@path/to/test.rb:1 # selects `Integer#times@path/to/test.rb` (bad)
Integer#times path/to/test.rb:1 # selects `path/to/test.rb` (good)

So a @ before the path was confusing probably most terminals.
OTOH at least ptyxis and Gnome Terminal stop at : so don't select the : at all.

I'm +1 for this issue because I think it does look cleaner and more readable without the : before in, and it's more consistent with from:
in is not part of the source code location so it should be separated with a space like from location in 'Class#method'.
i.e.

-	from some/file.rb:1:in 'Kernel#tap'
+	from some/file.rb:1 in 'Kernel#tap'

Compatibility concerns might mean it's not worth it though.

[Eregon (Benoit Daloze)]

There is also a good point that what follows a second : should be the column and not in, that's standard in many tools, including gcc and clang which look like:

$ echo 'int main() {' > a.c
$ gcc a.c  
a.c: In function ‘main’:
a.c:1:1: error: expected declaration or statement at end of input
    1 | int main() {
      | ^~~
$ clang a.c
a.c:1:13: error: expected '}'
    1 | int main() {
      |             ^
a.c:1:12: note: to match this '{'
    1 | int main() {
      |            ^
1 error generated.

Since Ruby doesn't show the column, there should be no second :.

(FWIW gcc/clang have a third : but at least there is a space after)

[headius (Charles Nutter)]

Is there any de-facto standard syntax that editors might interpret as a file + line combination? It would be extra great to make such stack trace output clickable AND go to the right line.

Other than supporting changes to make this output more terminal-friendly, I have no specific comments.

[byroot (Jean Boussier)]

Is there any de-facto standard syntax that editors might interpret as a file + line combination?

Yes, it's <path>:<lineno>, support isn't universal, but that's the most widely supported pattern. Even github does support it in it's file browser.