Automatically detect if no programming language is present to show overview in data-only repository

[quazar-omega]

Hi!

Summary 💡

Even in repositories where there are no programming languages (e.g. https://github.com/LemmyNet/lemmy-ansible) but only data/configuration, by default you get this:

Error: Could not find any source code in this repository

Maybe in such cases it shouldn't ignore non-programming languages and produce an error output, but fall back to the other most prevalent language.

Motivation 🔦

Related to #1208.
I didn't know right away how to make YAML appear and I was confused because I saw that it was supported as a language, then I found that issue and understood, but it wasn't very intuitive.

Maybe it is also worth reopening that issue, I think an improvement there could be to enrich this error message with suggestions, like:

Error: Looking for programming language source code, but couldn't find any in this repository
       You can add the option `-T data/markup/...` to show the repository overview regardless

Or even better, based on the content of the repository, it could suggest which argument to provide to the -T option, though, if it's able to do that, it would probably be better to just do it without further user intervention, which falls back into this issue (idk, I'm confused because I'm not aware of all the possibilities)

[spenserblack]

Semi-related to #1305. Detectable files can be controlled with a configuration, and also a summary can be generated with different options to get different results.

[quazar-omega]

So do you think that the option should just be better represented?
IMO, even just a more verbose error message would suffice as I feel like it's more of a discoverability issue and the current error text sounds a bit misleading at first sight

[spenserblack]

Yeah, I do think updating the error message is a great start. I was kind of just hinting at how this could be handled in the future and investigating the idea of automatically removing filters if nothing is detected.

[quazar-omega]

Oh, I see now!

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[quazar-omega]

Sorry, but I really have to say this, is this stale bot really necessary? I don't wanna tell anyone how to run their projects, but issues are just meant to track the status of a certain bug/feature/whatever. In long running projects they could go unaddressed for months or years, doesn't mean that nobody cares about them anymore, because most of us are pressed for time, but anyone could come at some point and bring new life to it, be it a PR or further discussion.
Otherwise, if you use it as points that need to be closed as soon as possible, because you feel like they create mental clutter for the maintainers, just go ahead and close this as not planned, but to me, in the end, it just leads to more scattered discussions like what happened with #1208: it was closed, I had a very similar suggestion and, instead of continuing from where it was left off, I created a new issue (and it's not so often that reporters dig into all past issues to link stuff together), maybe I shouldn't have, seeing as that was closed to begin with? I don't know.
If the stale tag didn't come with the implication of imminent closing, then it would all be fine and it would still enable you to filter them out, but at least it doesn't shut the door in the face of us reporters and the greater community for no specific reason.

[spenserblack]

TBH I agree. This project hasn't really been active enough these days to warrant a stale bot IMO. It's not like there are too many issues being created right now for us to handle 😆

I think it makes more sense in a project that's rapidly getting new commits all the time and/or getting a lot of new issues.

[o2sh]

Agreed ac7e2b8, we can always bring it back in the future if needs be.

[quazar-omega]

I'm really glad that you understand! I wasn't expecting this kind of response, thank you!! 🙏