4.5
In the same way that you can click on debugger errors to jump to the line of code that caused the error it would be very helpful to me if I could click on a printed message in the Output panel and jump to the line of code that generated that message.
wchc
November 19, 2025, 10:01pm
2
You can already do almost the same with the print_debug() function
Built-in GDScript constants, functions, and annotations. Description: A list of utility functions and annotations accessible from any script written in GDScript. For the list of global functions an...
It will give you a trace of where the print came from, down to a line number, like so:
Test print
At: res://test.gd:15:_process()
You are not able to click on it, but that seems to be a minor inconvenience.
3 Likes
I think godot already have it in the 4.6 or so
wchc
November 19, 2025, 11:28pm
4
There is this PR
master â mihe:clickable-diagnostics
opened 10:00AM - 10 Jul 25 UTC
Fixes godotengine/godot-proposals#1628.
Fixes godotengine/godot-proposals#10000⌠.
Relates to #57896.
Relates to #87216.
This makes the file and line part of error messages in the Output panel clickable, by simply wrapping both in a `[url]` BBCode tag, parsing those URIs in `EditorLog::_meta_clicked` and then opening the file in much the same way as the editor normally would, either in the built-in script editor or external editor, depending on the user's editor settings.
This PR takes a more conservative approach compared to #57896, by not trying to find every possible URL in the log and instead only concerning itself with the thing we already know is a file path, which saves us from any costly/error-prone parsing of the log itself.
One potentially controversial change here is that `EditorLog::_meta_clicked` will now early-out if it gets passed an invalid URI, meaning anything that doesn't start with something like `res:`, `file:`, `mailto:` or whatever else. The reason for this being that errors/warnings emitted from C++ will include relative file paths (e.g. `editor/editor_log.cpp:201`) which I couldn't see an easy way to deal with, and forwarding those to `OS::shell_open` will typically open the user's browser at that (bogus) path, so I opted to have it do nothing instead.
We could of course just not wrap the relative C++ paths in `[url]` to begin with, but again, I wanted to avoid any type of costly/error-prone parsing during logging if possible.
I'm happy to change it back to default to `OS::shell_open` for all non-URIs, but I figure since the express intent of #87216 was to allow for things like `file:` and `mailto:` then this behavior might be desirable anyway.
Coming with 4.6 dev 2
But it only says about the errors and warnings.
1 Like
Kuba:
Coming with 4.6 dev 2
Thatâs already out. We are currently on 4.6-dev4 as of this week.
2 Likes
wchc
November 19, 2025, 11:39pm
6
I know, but it still doesnât provide the feature OP requested. At least it doesnât seem like it. I havenât tested it yet myself.
1 Like