Add option for disabling semantic highlighting on macro command lines

[MulverineX]

Lots of users would rather have the more arbitrary/unsafe/misleading colors because it looks nicer, this would serve as a good stopgap until we have support for strict macro lines

[misode]

I personally don't think we should add this

[TheAfroOfDoom]

I personally don't think we should add this

despite me also preferring @Calverin 's current macro colorizing, i think there's two reasons we should add this:

• us not having it is a feature regression from v3
• being behind a default-off config makes it more the user's fault if they turn it on (that is, the risks of colorizing macro lines with a false sense of confidence)

[NeunEinser]

I am against this kind of config.

• Handling it like this in v3 was a mistake in the first place
• There are very good technical reasons we cannot have semantic coloring here for now
• We already have an answer for this in the future when IMP doc provides typedefs for macro arguments

[TheAfroOfDoom]

i think the fact that JS's eval has non-zero semantic coloring in some editors (as discussed in Discord) supports this being implemented in Spyglass, even if behind an optional config setting

[TheAfroOfDoom]

There are very good technical reasons we cannot have semantic coloring here for now

can you elaborate on this? maybe i'm misunderstanding what "semantic coloring" is. (what do we call what syntax-mcfunction does? vs. Spyglass's colorizing?)

[NeunEinser]

There are very good technical reasons we cannot have semantic coloring here for now

can you elaborate on this? maybe i'm misunderstanding what "semantic coloring" is. (what do we call what syntax-mcfunction does? vs. Spyglass's colorizing?)

Semantic coloring is semantic (duh) while syntax mcfunction doesn't take semantics into account and only looks at the command lines without knowing existing commands and actual argument types.

In semantic coloring, you can have different colors for the actually parsed nodes (like an underscore for vectors, yellow for resource locations, orange for unqouted strings, etc), while non-semantic coloring just uses some regex-like parsing to color nodes without taking the actual type into account.

Essentially, this was stating that there are some deeper changes we need to make if we wanted semantic coloring, to dismiss the potential argument of "just use some heuristic when encountering a macro argument and provide proper semantic coloring if you don't like that hack of disabling semantic coloring".