Skip to content

Feature suggestion for small language creators: keep .gitattributes linguist-language overrides with unknown name in languages bar #14528

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ell1e opened this issue Jan 30, 2021 · 7 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first. type/upstream This is an issue in one of Gitea's dependencies and should be reported there

Comments

@ell1e
Copy link

ell1e commented Jan 30, 2021

  • 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:
Screenshot from 2021-01-30 17-30-04
Mockup how this could look like with this feature:
Screenshot from 2021-01-30 17-30-04-2

@lafriks
Copy link
Member

lafriks commented Jan 30, 2021

Currently Gitea does not support reading gitattributes file

@lafriks lafriks added the type/upstream This is an issue in one of Gitea's dependencies and should be reported there label Jan 30, 2021
@a1012112796 a1012112796 added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Feb 1, 2021
@lunny
Copy link
Member

lunny commented Feb 1, 2021

And the language bar is not branch special.

@ell1e
Copy link
Author

ell1e commented 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
Copy link

@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
Copy link
Author

ell1e commented 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
Copy link

Currently Gitea does not support reading gitattributes file

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
Copy link
Member

6543 commented Sep 10, 2021

fixed by #16773

@6543 6543 closed this as completed Sep 10, 2021
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first. type/upstream This is an issue in one of Gitea's dependencies and should be reported there
Projects
None yet
Development

No branches or pull requests

7 participants