Open MulverineX opened 1 month ago
I personally don't think we should add this
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:
I am against this kind of config.
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
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?)
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".
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