feat: highlight component tag as HTML entity

[IgnaceMaes]

Origin: https://discord.com/channels/480462759797063690/518154533143183377/1218860748227481671

Open this PR for discussion!

GitHub syntax highlighting:

HBS	GJS

My main readability issues:

1. In .gjs, component invocations are highlighted as value, which makes sense because that's what it is in the language. However, I feel like the highlighting as DOM node in hbs provides more clarity/contrast. (this is also how Vue does it, haven't checked other languages)
2. Braces {{ ... }} are highlighted in red. This feels to me like it's an error in the code. The coloring in hbs seems nicer here.

Adapting the first point:

Before	After

Now seeing that in action, not sure if it's an improvement in VS Code 🤔 VS Code already does not reuse the same color for the component invocation name and the properties, which seems to be the main quirk on GitHub.

[lifeart]

@IgnaceMaes I personally like Idea to differentiate between tags and components (it's design decision),

I like before case because it's explicitly mark "dynamic" parts.

But, I do agree, GH colouring is not perfect, and that we could do here:

• Get all color tokens github support and create independent syntax version for it.
• Chat with GH team and figure out better color accents (also, checking dark mode).

[evoactivity]

Getting GH team to do anything to change colours is unlikely. The linguist project only classifies the languages, syntax highlighting is an internal team we can't talk to.

I agree components should be a different colour, I don't like it matching HTML, the scope could just be a different one to what it is now as the purple color in vscode blends the component name with it's arguments on github.

The braces could be changed I think to be scoped as something else too, closer to how HBS highlights them.

I'll play with some options next week and present something I think will make everyone happy.

[lifeart]

@IgnaceMaes, @evoactivity I think we need to create kinda priority list, to agree on parts we would like to highlight, to be able to make different decisions without breaking backward compatibility.

Priority list: (changes should be tested in following order, and should not downgrade DX)

1. VS Code
2. Other editors
3. Github

Some key concerns:

1. Components vs Tags (vs Slots?) should have different color to simplify dynamic/static parts recognition.
2. Args is already bolded by lang with @, so, no real need to add extra to arg name
3. It's important to highlight @ as language keyword symbol where it's used as reference, likely same for this.
4. Helper names should have different color comparing to it's arguments
5. Flow-control braces? should have special accent (if, else, each, yield, outlet)
6. Special keywords should be highlighted (true, false, undefined, null)
7. Numbers and strings should be highlighted
8. Braces in foo={{@bar}} cases should have its own accent (more neutral, to reduce visual noise)
9. Consistency - we need to try keep it approach consistent, but support corner-cases (like flow-control)
10. Readability - color accents should prioritise readability on large codebases (breaking (aka dynamic) parts should be visually prioritised over static parts))

Variability:

It's fine to fine-tune syntax for different editors/consumers if it's improve DX, we already have scripts to build syntaxes, all we need is figure out general approach on how to keep it in control and not blowing source codebase.

This concerns is not final, but kinda foundation for "language highlighting design", we should agree on parts we not planning to change, to be able to improve other cases.

[evoactivity]

I agree with your concerns there @lifeart.

I would also suggest two things

• We can use whatever scope gives us the colouring we want rather than only using them if they strictly true, eg using variable.constant for something that isn't a constant if it colours it nicer, should be ok for us to do.
• GitHub/textmate doesn't need to match one-to-one to other editors and allowing for differences should be ok

I found a textmate theme that implements githubs colours, so I should be able to figure out scope names that colour github better but also keeps vscode nice as well. I'd prefer to find a happy balance that works everywhere rather than have different grammars for editors vs github, but I won't rule out having different grammars if it's an absolute must.

So textmate (and therefore github) doesn't have anything setup in the theme for entity.other.attribute-name which is why component invocation and attributes are coloured the same as they are just coloured as entities. Also support.function doesn't seem to exist in the theme so this.thing is coloured as one colour because variable.language and support have the same value. There will be several cases of this.

I'll keep playing around and see what I can come up with.