Open enetheru opened 2 months ago
As stated on the PR I'd rather expose an get_file_path
method, so that this can work with text files that are not integrated with the resource system. It also reduces complexity (I doubt the current implementation of the edited resource approach would handle all cases that could arise from custom resource loaders gracefully).
I disagree, that would be adding additional methods which essentially duplicate information already available. The call is being exposed in the EditorSyntaxHighlighter, returning null on no resource is already what it does, except always. All i'm adding is that the editor correctly sets the resource when its loading it, and making the method visible.
This functionality already exists within the sister editor plugin ScriptTextEditor, the call to set the resource is there, and the method while hidden is available.
ScriptTextEditor is always tied to a resource, and I understand that at least for your use case this method is enough. But in my opinion a lot of exposed editor/gui functionality has the problem that the api is very limited to cases that Godot needs internally.
It might have been the original intention to expose this as is, but the fact that it was not done correctly gives us the option to put a little thought into what to expose now.
Having raw text files that are not tied to a resource is a valid use case, I think I have seen it in an dialogue plugin at some point. Your proposed solution can not support this case, but I think we should account for it.
And duplicate functionality is not really a concern IMO, it would probably boost your 2 line solution to lets say 25 lines at max.
Boosting line count is the antithesis of my desire. I prefer least impact, most obvious, I'm not keen on a new project, I already have too many things to do.
Only exposing a string will safe us maintenance work in the long run, since it removes the interaction with the resource system which is more likely to cause bugs.
Describe the project you are working on
flatbuffer addon It uses both c++ for the integration with the flatbuffer library, and gdscript for editor integration and syntax highlighting Specifically this proposal is about syntax highlighting.
Describe the problem or limitation you are having in your project
I am unable to determine the file and location that is being edited from within the highlighter, preventing resolving types from included files that use relative path names.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Exposing the get_edited_resource() from the editor TextEditor and correctly setting that resource on change of syntax highlighter will allow resolving the path to the file.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
https://github.com/godotengine/godot/pull/96058
two line fix
If this enhancement will not be used often, can it be worked around with a few lines of script?
it cannot be worked around, there is, at present, insufficient introspection available within gdscript to determine the edited file from the syntax highlighter class, or anything it has access to. I am open to being proven wrong.
Is there a reason why this should be core and not an add-on in the asset library?
It requires changes to the c++ to resolve the deficiency, that allows addons to perform optimally.