feat: add data-lexer-name attribute to file-info-entry

[lavamini]

This makes it easy to customize syntax highlighting.
e.g., in templates/custom/header.tmpl.

/* Lexer name: Go */
:root:has(.file-info-entry[data-lexer-name="Go"]) {
  /* Add custom syntax highlighting */
}

[wxiaoguang]

Since the new attribute is not used in the current code base, it needs a clear comment to describe why it is added, otherwise it would be removed in the future again when some people find that it is not used.

[wxiaoguang]

By the way, if your customized highlighting is a general requirement, it's better to add it in Gitea or upstream Chroma https://github.com/alecthomas/chroma

[lavamini]

At its core, Chroma is a lexer ported from Python's Pygments rather than being based on an Abstract Syntax Tree (AST). Because of this, its inability to recognize certain syntax is a fundamental flaw baked into its design. To work around this inherent limitation, I am planning to use frontend CSS to manually supplement and patch up the syntax that Chroma fails to recognize.

[wxiaoguang]

I am planning to use frontend CSS to manually supplement and patch up the syntax that Chroma fails to recognize.

That's a huge work. Not only frontend CSS, you also need frontend syntax parser, a lot of details then.

By the way, could you show some bad cases which need to be patched?

[lavamini]

1. Currently, syntax highlighting applies the exact same color scheme across all languages, and several valid keywords are left unhighlighted. Giving users the option to customize syntax highlighting for individual languages would be a massive improvement.

2. By allowing users to load custom styles from a local custom directory, this configuration remains completely isolated and won't affect anyone else.

3. Implementing this is straightforward: we just need to inject a data-lexer-name attribute (e.g., data-lexer-name="go") into the container.

4. This not only makes things incredibly convenient for users looking to patch specific syntax limitations, but also adds a unique, powerful feature to the project: fully customizable syntax highlighting.

[lavamini]

This is some bad cases.

[wxiaoguang]

This is some bad cases.

TBH, IMO it's arguable whethere they are really "bad cases"

If you'd really like to patch them, what's your plan? how would the CSS selector be used?

[lavamini]

[wxiaoguang]

I see your description, but how to?

What will you write to replace the /* Add custom syntax highlighting */? I don't see a feasible approach at the moment.

[lavamini]

e.g., Port should be tokenized as nv, not nx.

[wxiaoguang]

e.g., Port should be tokenized as nv, not nx.

So you are fighting with Chroma's highlighting result, such case should be fixed by upstream Chroma.

[lavamini]

I do not need to fight with Chroma's highlighting result.
I just need to correct the token color like 'Port'.

[lavamini]

e.g., Port should be tokenized as nv, not nx.

So you are fighting with Chroma's highlighting result, such case should be fixed by upstream Chroma.

Chroma can't resolve this token issue like 'Port'.
it is an inherent limitation of Chroma.

[lavamini]

If I want to provide different colors for keywords in different languages, what's a better way?

[wxiaoguang]

I do not need to fight with Chroma's highlighting result. I just need to correct the token color like 'Port'.

"nx" means "NameOther", you will highlight all "nx" symbols appearing in Golang source code in the end, it's impossible to only highlight the fields like "Port" in the struct.

---

I don't think it is a right approach, while I won't block this change as long as it doesn't cause new problems and it is maintainable ( #37791 (review) )

[lavamini]

/* ok, this may be a joke, but I'm working on it */

[wxiaoguang]

/* ok, this may be a joke, but I'm working on it */

• feat: Added gitea-dark-github style theme feat: Added gitea-dark-github style theme #37259