The editor should not be formatting enum keys

[sancho2]

When using @export with a variable of an enum type the keys are formatted such that the first letter of each word is uppercased and underscores are removed.
I would expect that an enum key be displayed as defined and not be formatted in any way by the inspector.

enum test {ONE_TWO, THREE_FOUR}
@export var ooo:test 

The underscore and casing are integral parts of the value.
For example this line is perfectly valid syntax in GDScript:
enum {ONE, _ONE, one}
Each of these enum keys will be displayed as "One" in the inspector. That's not good.

Enum keys are values when an enum type is exported. Very much like an exported string value.
If you
@export var my_string:String = "my_value"
The editor keeps case and underscore.
Similarly, enum keys should not be modified in any way.

[Mickeon]

I would expect that an enum key be displayed as defined and not be formatted in any way by the inspector.

I believe I can safely say that this is the unlikely expectation, given how most options for enum properties in the Inspector (and Project/Editor Settings) are capitalized. UPPER_SNAKE_CASE has a meaning in code, but not so much when displayed to a Godot user (which may not be a programmer).

It is true that without the original underscores and casing, there might be duplicates. In a typical project, however, this is highly unlikely, given all constants (especially within an enum) are expected to follow the same casing convention.
In the case of duplicates, the Inspector could fall back to using the original names, without formatting. The current behaviour could be considered an oversight, or a bug.

[AThousandShips]

It can absolutely guess as it follows a standard format

[dalexeev]

I think it's just a matter of readability. Property names are snake_case by convention, but it's more readable to display them capitalized and trim common prefixes from groups/subgroups. Enum values ​​are UPPER_SNAKE_CASE by convention, but it's more readable to capitalize them too. That way they take up less horizontal space and aren't too distracting.

[sancho2]

Its a matter of context.
In the context of an enum being selected from the inspector it is a value more than anything else.
Godot can guess what a string value is and in some rare cases be correct. But it shouldn't be doing that and it doesn't.
Because it cannot guess that value with any degree of accuracy because context is totally absent; how that value is being used is non existent info to the engine. Rightly so Godot doesn't add $ or commas to numbers within strings and it doesn't fix puntuation on text values.

In the case of a variable name you have context and therefore it isn't too far a stretch to format that variable name for display.
Godot approaches enums as though the enum values where variable names.
When writing code they are variables (or close enough) but in selecting them in the inspector they are values.
And again, there is no way that Godot can guess at how that value is being used any better than it can guess what the is the context of a value of a String or an int or float or any other value.

[Mickeon]

When writing code they are variables (or close enough) but in selecting them in the inspector they are values.

When selecting them in the Inspector, they are not values. When String enums are used, the Inspector displays the values as defined by the developer, hence they're not formatted. When int enums are used, the Inspector displays representations of the values in the enums, which are derived from the constants' name. They are not the values themselves.

Keep in mind the Inspector visualization is accomplished with PROPERTY_HINT_ENUM (corresponds to the @export_enum annotation in GDScript). Hence, in the worst case scenario, this can be addressed manually.

[sancho2]

I was not talking about string enums.
I was talking about exported string values. See the example in the first post.
Using string enums is actually a valid workaround though.
It actually kind of proves the point.

[timothyqiu]

I'd say that the dropdown menu is not showing enum keys, it's showing human-readable names for each enum value.

The thing is, we auto-generate those names by capitalizing ENUM_KEYS. The auto-generation algorithm works for most practical cases, but fails for corner-cases like enum SomeEnumType {ONE, _ONE, one}.

One workaround is to use @export_enum("ONE", "_ONE", "one") var ooo: specifying those names manually instead of auto-generating. The downside is that ooo is typed int instead of SomeEnumType. It'll be better if we can allow @export_enum on enum typed variables.

[Mickeon]

Again, the algorithm could also fall back to using the original raw names, in the edge case of conflicts.