Allow specifying additional files types & grammar files for syntax highlight from within the repository
(This issue was created since gitlab-foss#27690 (moved) was closed)
Please add support for specifying additional files types & grammar files for syntax highlighting in gitlab's code view from within the repository itself, preferably as a static syntax description files & file extension and NOT arbitrary parsing code alike to TextMate/Atom-style highlighting files which work largely with a mix of replacement rules and regular expressions. While these aren't as perfect as an arbitrary parser, they usually are "good enough."
Why is it useful?
-
Supporting important but niche languages. Niche domain specific language projects, while important in some real world uses, might not ever be significant enough for inclusion into rouge or linguists even if long-lived. This feature gives both the creators of those languages and users the possibility of having associated files properly syntax highlighted and labeled, if they manually take care of it. (Better than nothing/the current situation)
-
New languages are fostered. People who make new languages who might not know yet if they even continue them can have proper statistics and highlighting on GitLab of their main repo, without cluttering rogue or linguist. With this, the devs can show off their work better. This would also
-
Encouraging of marking incompatible forks as such. E.g. Lua has the official variant and LuaJIT, both are commonly tracked as "Lua". However, code for the latter might be written using features that are fundamentally tied to LuaJIT, like it's FFI interface. People could manually label this correctly as not-actually-lua to signal this, without giving GitLab's language detection the impossible task of detecting this.
-
Possible support on gitlab.com. With implementing this as a static rule format rather than dynamic parsing code in ruby or whatever, it should be possible to roll this out on gitlab.com itself easier in regards to security implications. Denial of service / sane limits on syntax rule complexity would obviously still be an issue, but at least malicious code execution should be far easier to avoid.
-
Attract language developers from GitHub. Implementing this would possibly attract language developers to GitLab, since GitHub is also not supporting this feature. I know I would certainly move.
A few people voice support on the original locked issue so there appears to be at least some interest.
Ideally, it should be possible to either override the language name while reusing an existing syntax, e.g. for cases like the Lua-but-not-quite example above, or to override both the language name and provide a new syntax highlighting grammar. I would suggest some .gitlab-languages.yml or alike to allow this.