Description
- Gitea version (or commit ref): 1.14.0+dev-546-gdc66e4740
- Git version: ???
- Operating system: docker
- Database (use
[x]
): should be irrelevant - Can you reproduce the bug at https://try.gitea.io: did not try, since it's not a bug
- Log gist: not a bug
Description
I have a feature suggestion for small language creators: keep .gitattributes linguist-language overrides with unknown name in languages bar. This has also been suggested for the original linguist and GitHub here, but GitHub seems to query language names from a central database and isn't interested in adding extra code to allow repo-only entries indirectly created by .gitattributes
entries.
Basically, when .gitattributes
contains a line like this: *.h64 linguist-language=Horse64
, and the language Horse64
isn't known to gitea / go-enry, then it would be cool if it still showed up with the name "Horse64" and any random color choice in the languages bar. I checked this on my own gitea instance (running 1.14.0) and right now this isn't the case, same as on GitHub the unknown language classification is just plain ignored and omitted.
Screenshots
Project with *.h64 linguist-language=Horse64
line and some .h64
files looks like this:
Mockup how this could look like with this feature:
Activity
lafriks commentedon Jan 30, 2021
Currently Gitea does not support reading gitattributes file
lunny commentedon Feb 1, 2021
And the language bar is not branch special.
ell1e commentedon Feb 1, 2021
Ah interesting. I'm actually not sure if it changes on GitHub for each branch or even commit you're looking at, but so far I would have assumed it probably does...? I never really paid attention to this detail though. If this was just based on the main branch I still think it'd work sufficiently well for most projects though.
alexanderadam commentedon Feb 7, 2021
@ell1e maybe it would be easier to add this language to go-enry?
By the way, this line implies that the
.gitattributes
feature is planned, though. 😉ell1e commentedon Feb 7, 2021
@alexanderadam no, this is a general problem of quirky side languages, this just doesn't scale. So just "getting it added to {library that is meant for serious syntax highlighting/lang identification}" is usually not in anybody's interest. Nobody wants that filled up with small hobby languages that might be discontinued, yet these hobby languages have a real use in having their repos not completely wrongly annotated in statistics if they can help it via manual
.gitattributes
entries. So there is a real need for being able to being able to define these on a per repo basis for the quirky languages community. And I think the least effort way on gitea's side to enable this would be to allow manual per file overrides in.gitattributes
to custom made up language names that aren't otherwise known to the gitea instance.spacekookie commentedon Feb 17, 2021
Is this on the roadmap to support some time? I couldn't find an issue about it.
I generally vendor a lot of code into a big mono-repo and the language bar is pretty useless to me (and I wish it wasn't!). Being able to ignore subtrees with regards to the language statistics would be very nice.
6543 commentedon Sep 10, 2021
fixed by #16773