Make file part of errors/warnings clickable in Output panel #108473
Conversation
|
This seems to also close godotengine/godot-proposals#10000 I think edit: seems like you added that to the description while I was making my comment :D |
mihe
force-pushed
the
clickable-diagnostics
branch
from
230206c to
49c615b
Compare
Does this also work for |
No. Those paths are not added (or otherwise parsed) in I'd prefer to keep this PR limited to errors/warnings, since that's what the two proposals are about. |
There was a problem hiding this comment.
Tested locally, it works as expected. Code looks good to me.
However, note this only applies to the Output tab. Errors/warnings are only visible if they were printed by the editor, which means only @tool scripts will benefit from this change (as errors/warnings printed in the running project appear in the Debugger > Errors tab instead).
Also, links to C++ source files will appear to be clickable, but will do nothing when clicked.
The main motivation for this was being able to click the paths of GDScript parse errors, where this also applies.
Indeed, and those are clickable already.
Yes, that would be the "potentially controversial change" mentioned in the PR description. I was toying with the idea of maybe being able to open up GitHub links to the actual file and line for C++ errors, since we should have the commit and everything, but that probably gets messy very quickly, especially when you start involving custom forks, custom modules and godot-cpp errors and whatever else there might be. |
mihe
force-pushed
the
clickable-diagnostics
branch
from
49c615b to
04d6e89
Compare
|
I forgot to escape |
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 inEditorLog::_meta_clickedand 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_clickedwill now early-out if it gets passed an invalid URI, meaning anything that doesn't start with something likeres:,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 toOS::shell_openwill 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_openfor all non-URIs, but I figure since the express intent of #87216 was to allow for things likefile:andmailto:then this behavior might be desirable anyway.