Create a script template manager for the editor

[Xrayez]

Describe the project you are working on:
Goost - Godot Engine Extension.
Project-agnostic, editor-related.

Describe the problem or limitation you are having in your project:
I have quite a bunch of abstract (base) scripts which can be treated as script templates. The problem is that it's not really obvious how to create them, and oftentimes requires you to open up an external filesystem explorer just to locate and modify them, and in fact there are several places where these templates can be located now: godotengine/godot#31111 (project-specific templates alleviate the issue to some extent).

The ability to create the script templates seems like a hidden feature for many users as well, and it's currently undocumented: godotengine/godot-docs#398 documented now, see Creating script templates page.

The exact syntax for placeholders is also not obvious, unless you lookup the default script template located per editor, some example:

extends %BASE%

func _ready():
%TS%pass

Also additional type placeholders like:

"%INT_TYPE%", ": int"
"%STRING_TYPE%", ": String"
"%FLOAT_TYPE%", ": float"
"%VOID_RETURN%", " -> void"

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I propose that it would be good to create a ScriptTemplateManager control, and you won't have to document it that much being user-friendly.

Currently there are two places where templates can be found:

1. Project-specific templates, for instance: res://script_templates, which is the default path.
2. Editor templates, located at %APPDATA%/Godot/script_templates/.

There can be several scripts per each language supported:

• empty.gd (GDScript)
• empty.cs (C#)

The default template is always generated dynamically per language.

Then, the ScriptTemplateManager would just list either project or editor templates, and filter them per language, and of course allowing the user to create, modify, and delete existing templates. Having a bunch of buttons to insert built-in placeholders like %BASE% would also be nice.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Some generalized mockup for the sake of giving an idea:

Of course there would be a text editor which will allow you to actually modify the template, and some icons to rename/remove the individual templates from the list.

Some back-end is also already implemented as described in godotengine/godot#31111 (comment). So there's another important part of telling whether project-specific templates override editor ones (this logic is currently hard-coded within ScriptCreateDialog and likely can be moved to ScriptTemplateManager as proposed here.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It's totally possible to use script templates without this.

Is there a reason why this should be core and not an add-on in the asset library?:
Some things are inaccessible to scripting, namely:

• ScriptServer which can be used to list supported languages to be displayed in the manager (UPDATE: linking a PR which helps to implement this on the scripting side: Add cross-language script class support and expose the ScriptServer singleton godot#40147)
• ScriptLanguage is not exposed to scripting either to generate default templates:

virtual Ref<Script> get_template(const String &p_class_name, const String &p_base_class_name) const = 0;
virtual void make_template(const String &p_class_name, const String &p_base_class_name, Ref<Script> &p_script) {}
virtual bool is_using_templates() { return false; }

So partially it's doable, but do users really have to suffer the lack of usability of the built-in feature already present in core?

[groud]

It looks like a good idea to me to integrate templates a little bit more. We could maybe create a template resource and use the script editor for it.

That being said, I don't know how often this feature would be used, so it might not be worth the maintenance work.

[Xrayez]

I also think this might not be worth the work. Nonetheless as you said, it may be necessary to expose some methods to allow plugins to implement this perhaps (depends on #831 to make it available globally for editor builds, else doesn't make much sense, I wouldn't need to create this proposal in the first place), and I'm not really that interested in implementing this currently, so closing.

[Xrayez]

Reopening because the proposal makes sense to me, the manager won't likely be implemented directly in Godot, but there are still API issues, some editor stuff needs to be exposed to scripting. For now this is a good candidate for implementing in Goost as listed in goostengine/goost#7, because it's totally possible to access those features via C++ module currently.