Add C# Editor Documentation

[HaSa1002]

The user can select, how the reference should be rendered in the editor settings.
text_editor/help/class_reference_language: GDScript

text_editor/help/class_reference_language: C#

The conversion to PascalCase is done automatically.

This is moved out of #40613

[aaronfranke]

Maybe we should make a method on String to do this? I think it would be more efficient, we could make a method that doesn't involve string splitting and re-concatenation - we can simply capitalize every letter after _ (and at the beginning) and then afterwards do a find/replace "_" with "" (except keep one at the beginning if there was one).

[Calinou]

I'd try to benchmark that code to see if it's an actual bottleneck first (even using good old OS::get_singleton()->get_ticks_usec()). Adding more code to the String class should be done cautiously.

[HaSa1002]

Will do, but this code is not executed in a performance critical part of the engine. I can test wheter or not a iteration above the whole string is faster

[Geequlim]

Please add C# related macro checking, this features should not exist in the engine without C# support.

[HaSa1002]

There's a MODULE_MONO_ENABLED define (defined in modules/module_defines.gen.h or similar).
But more than hardcoding this in editor code, it would be better to query the available script languages drop the engine to see which are included in the build.
It could additionally be made configurable via an editor setting whether you want to see GDScript, C# (when available), or all.
was the statement by akien on the other issue. I would vote for the option of having it setable in the EditorSettings and make default if C# is existent. It's always a runtime feature and it's generated from the GDScript docs.

[neikeq]

I'm not necessarily against this, but it's not the ideal way:

• While identifiers are converted to PascalCase, there are exceptions like when there's a conflict with another name, in which additional alterations are applied (like suffixing with Enum or an underscore _).
• This only includes Godot Object derived classes, not other classes or structs. It also doesn't include C# specific methods/properties we add to Godot Objects that are not present in ClassDB.
• No info about namespaces either. There's a high chance some classes will be moved to a different namespace in the future, like File/Directory and Thread/Mutex/etc.
• No .NET specific members like events.

IMO, the best would be to generate these from the information we get from the API assemblies and their generated xml doc file.

[neikeq]

Also -not a blocker either as this can be done incrementally in future PRs- but it would be better if this wasn't hard-coded in EditorHelp. Instead EditorHelp should allow third-parties to inject documentation providers.

[mhilbrunner]

Closing due to lack of consensus as discussed above, and as this has been gathering dust for a while. Thanks for contributing. :)