Improve && and & syntax highlighting by altering StringName highlighting

[Wierdox]

Describe the project you are working on

A game, with the main text editor being Godot.

Describe the problem or limitation you are having in your project

The StringName(and by proxy &&(and) and &(bitwise and)) syntax highlighting is a bit of a mess.

• On new lines(mainly using \), the first ampersand of && or & are the color of StringName highlighting. This really irks me, it's the only reason I haven't used && over and. As an anecdote, my first impression of seeing it in 4.x(videos online) is that godot was unprofessional and I couldn't understand why such a glaring flaw like that would hang around.
• It's misleading too. If the & is spaced away from the quotes, it stays the color of StringName, despite being parsed as & or else borked. Due to my unfamiliarity, that quirk made me think you could space out the & if you wanted to. If the syntax highlighting changed, it would be much harder to confuse.
• For some reason, the 3rd & in a row after && is the color of StringName (not pictured). Just strange and I don't know why it's there other than just 'cause. It goes back to symbol color after the 3rd.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Simplifying StringName highlighting would be the best, just make the ampersand symbol colored unless directly next to '/"(and not inside of another color block like strings). If there are arguments to the contrary, I would hear them out.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Link to my PR: godotengine/godot#100575
Here is the comparison. I think it's a more consistent coloration that most wouldn't notice, but advanced GDScript users should enjoy. As in, bitwise and using && is on the rarer side, especially for newcomers.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, as far as I know this syntax highlighting is baked into the text editor. You could work around it by changing StringName color to match the symbol color, but now your StringNames look like symbols or vice versa. Not a good compromise.

Is there a reason why this should be core and not an add-on in the asset library?

See above section.

[Mickeon]

Not sure why this would need a proposal. It's an objective improvement. If anything the current behavior looks to be a bug,

[Mickeon]

Anyway, for the highlighting, it's somewhat related to:

• Improve StringName and NodePath usability #4721

[Wierdox]

Not sure why this would need a proposal. It's an objective improvement. If anything the current behavior looks to be a bug,

You're probably right. The main thing that made me do this instead of just a PR was how: the current highlighting makes the & immediately turn the color of StringName at the start of the line or the first symbol in a function call or expression, which makes sense since a leading & would likely be for a StringName you haven't started the quotes for. This would be more responsive and could also hint to an unaware user that StringNames are a thing. However, due to lacking multiline context in syntax highlighting, it causes problems when making use of newlines for long expressions.

Due to that, I thought there could be some pushback and made it a proposal.