Expose reload_scripts as reload_open_files

[KANAjetzt]

Expose the reload_scripts method to match the current state of the 3.x branch.

As described in #83118, it is possible to replicate this method with GDScript:

static func reload_script(text_edit: TextEdit, source_code: String) -> void:
	var column := text_edit.get_caret_column()
	var row := text_edit.get_caret_line()
	var scroll_position_h := text_edit.get_h_scroll_bar().value
	var scroll_position_v := text_edit.get_v_scroll_bar().value

	text_edit.text = source_code
	text_edit.set_caret_column(column)
	text_edit.set_caret_line(row)
	text_edit.scroll_horizontal = scroll_position_h
	text_edit.scroll_vertical = scroll_position_v

	text_edit.tag_saved_version()

and set the text_editor/behavior/files/auto_reload_scripts_on_external_change setting to true.

Personally, I would prefer calling EditorInterface.get_script_editor().reload_scripts(), but I might not be aware of possible pitfalls caused by exposing this method.

This would also improve the porting of existing 3.5 plugins.

closes godotengine/godot-proposals#8111

[AThousandShips]

Please remove the special characters from the commit message and make it match the title of the PR

Also please open a proper proposal as asked on the issue, having a proper proposal where the proper arguments for this feature is important to gauge if this is needed

[AThousandShips]

@twaritwaikar do you recall if exposing this (i.e. making public) in 3.x was meant to be used in scripting, or was it renamed since it was made public on the c++ side?

This was done in #53900 but only for the 3.x side, so the fact that this was not done in 4.x to me implies that it was not intended to be exposed as such

Edit: these changes were ported to 4.x in #62157 where this was not exposed

[Qubus0]

This is useful (and used) for all plugins that modify any (active) scripts.
I'm not sure why it would not be intended to be exposed. Would there be any downside to having it exposed or is it a case of needing a certain degree of usefulness to be justified?

[AThousandShips]

Exposing internal methods, especially in the editor, binds the development to maintain compatibility and stability, so that's why I asked for a proposal to gauge the need and justification for this

If it can be worked around, how needed it is, etc.

Because exposing a method isn't a trivial thing that comes with possible issues and a burden of maintenance

[KANAjetzt]

What can I do to make the Linux check pass?

[AThousandShips]

See the error message, you need to reorder the entries of the documentation, they need to be ge sorted

[KANAjetzt]

Sorry for that unnecessary check, I hope I got it now 😅
The doctool got stuck when trying to delete the cache while VSCode was running.

[Paulb23]

Don't see a solid reason against exposing this for plugins, but I'm thinking we should start moving away from the script naming in this file a little bit as reload_scripts doesn't just reload Script, but any open file i.e TextFile and JSON.

So we should bind it as reload_open_files or something along those lines.

[KANAjetzt]

Thanks, @Paulb23 - I went ahead and changed it to your suggestion. Is there something to do now on the project converter side?

[KANAjetzt]

I added the function to the rename map, I hope we can get this merged for 4.3 👀

[svetogam]

The absence of this feature is painful to me. Two of my plugins would benefit from it. I hope it can get merged soon!

[Zephilinox]

I also need this, my usecase is generating gdscript code in open files. the file on disk and the data in memory is updated, but the opened scripts in the editor do not get updated

[Naros]

Correct me, but isn't this now exposed in ScriptLanguageExtension::_reload_scripts ?

[Zephilinox]

I did try that before but it didn't work. I suspect it's referring to script resources, and not the open script in the script editor, or maybe it's broken or I'm using it wrong 😂

[dawdle-deer]

Correct me, but isn't this now exposed in ScriptLanguageExtension::_reload_scripts ?

ScriptLanguageExtension is undocumented, so I'm shooting in the dark to an extent, but I believe it's unrelated. Internally, when changes to gdscript files are saved, a call is made to GDScriptTextDocument::reload_script, which calls ScriptEditor::get_singleton()->reload_scripts(true). It would make sense to expose this API in a similarly simple fashion.

[dawdle-deer]

Looks good to me!

[Qubus0]

Correct me, but isn't this now exposed in ScriptLanguageExtension::_reload_scripts ?

reload_open_files reloads script editors, not the scripts themselves. changes to the script are applied just fine, but if a script is changed programmatically (ex: preprocessors) and still open in a text editor, the editor doesn't update, forcing you to close and reopen to get the new changes. if you accidentally save it'll just override those changes

[kitbdev]

This can cause unsaved changes to be lost without confirmation.
It would be better to expose _test_script_times_on_disk (and maybe _update_modified_scripts_for_external_editor which is usually called after it?, effectively _on_find_in_files_modified_files) if needed.

text_editor/behavior/files/auto_reload_scripts_on_external_change is now true by default, so it won't show the confirmation dialog unless its unsaved.

A workaround is to send the ScriptEditor NOTIFICATION_APPLICATION_FOCUS_IN, since it calls _test_script_times_on_disk:

EditorInterface.get_script_editor().notification(Window.NOTIFICATION_APPLICATION_FOCUS_IN)

[kitbdev]

This does work when an external editor is active.

[KANAjetzt]

@kitbdev Thanks for your comment, sounds good to me. If you have a full picture of how to best expose this to plugin devs, feel free to open a new PR with your suggestions. It has been a while since I looked at the engine code, but I am also happy to dive back in if necessary.

[Repiteo]

Superseded by #116187; thanks for your contribution!