Open KoBeWi opened 2 years ago
(ignore that the symbol is darker; it should be the same)
But I kinda like it... 👀
I like the idea, but this may add a lot more colors for third-party syntax themes to support – especially with the leading symbols. Maybe the leading symbol color can be automatically generated using a lower opacity than the base color for StringName and NodePath.
And since
%
got it's special syntax (%UniqueNode
), we could allow unquoted StringNames and NodePaths too:
I don't think that's a good idea. It starts to remind me of Ruby, and not in a good way. At the end of the day, StringNames are still strings – the different type is mainly here for performance reasons.
Maybe the leading symbol color can be automatically generated using a lower opacity than the base color for StringName and NodePath.
Yes, that's how I'd like to see it work.
tbh I don't like the idea of darker symbols. It's just unnecessary. Although with quotes maybe makes sense; you get a different-colored string and actually the symbol becomes redundant. Or something.
It starts to remind me of Ruby, and not in a good way.
Ruby is great tho. I don't see any problem in skipping quotes; they are useless.
this may add a lot more colors for third-party syntax themes to support
Why is this even relevant xd They can just set the same color for every option.
(ignore that the symbol is darker; it should be the same)
But I kinda like it... 👀
I have to agree on this, I would love this on the $ syntax, I tend to avoid it, because the symbol makes it very hard to read, the darker version remedies this substantially.
This can be closed, right?
No, the second part of the proposal (unquoted StringNames and NodePaths) is still not addressed.
Ah mhm. Not too fond of the idea personally, I think it's nice to be clear those are just special types of strings. For NodeRefs ($MyNode
) it's fine, but for NodePath and StringName there are autoconversions with Strings.
I suppose we'd need to make symbols like /
and %
special cases to continue NodePaths.
StringName plays nicely with most of the ways it's used in the editor, but a few are still problematic, like get and set on a property with slashes. I personally wouldn't use it without quotation marks though. For example it's a common practice to use special symbols for translatable strings, which get passed to tr(StringName)
. Even if not, some of my uses of StringName are with whitespaces, which is perfectly normal for them, but not fine should I avoid quotations.
The literals are already highlighted in different colors:
Allow this and make it uniquely-colored in the script editor:
&StringName ^NodePath
This syntax can confuse users into thinking that pointers/references exist in GDScript:
node_2d.set(&global_scale, Vector2(8, 2.5))
tween.tween_property($Sprite, ^position, Vector2(100, 200), 1)
The quotes more clearly indicate that these are just special strings:
node_2d.set(&"global_scale", Vector2(8, 2.5))
tween.tween_property($Sprite, ^"position", Vector2(100, 200), 1)
Describe the project you are working on
A very big project I am converting to 4.0
Describe the problem or limitation you are having in your project
Godot 4.0 added StringNames as a type usable from GDScript. Many methods now expect StringNames (implicit String conversion is available though), but StringNames are also nice for custom methods that rely a lot on string comparisons, but don't modify the strings. So my code keeps getting new StringNames everywhere.
Another thing are NodePaths, which are used in some methods too. I neglected them so far, because when you use String it will just get automatically converted when needed, but using correct type makes the code faster and it doesn't hurt to use it.
My only problem is that syntax-wise StringNames and NodePaths are basically Strings with extra symbol at the beginning. This is nice for converting project, because you can just slap
&
to your strings, but not very convenient for new code and also it's less readable (mostly due to being colored the same as Strings and the extra symbol standing out).Describe the feature / enhancement and how it helps to overcome the problem or limitation
We have a special coloring for
$
operator:It should be the same for
&
and^
, i.e. StringName and NodePath could get their own unique color, so instead of we could have (ignore that the symbol is darker; it should be the same)And since
%
got it's special syntax (%UniqueNode
), we could allow unquoted StringNames and NodePaths too:Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Allow this and make it uniquely-colored in the script editor:
If this enhancement will not be used often, can it be worked around with a few lines of script?
Syntax part can be worked around by using quotes 🙄 but the custom highlighting part not.
Is there a reason why this should be core and not an add-on in the asset library?
StringName and NodePath are core types.