File colors

[vednoc]

Hi Andrew,

I implemented file colors based on GitHub's Linguist project. However, there are three issues that I've left unresolved:

1. Some languages have shared file extensions, so we'll need to implement some kind of override or simple language detection.

2. How should we handle files that require full base name (e.g. go.sum/go.mod) for colors to be applied to them?

3. How should we handle files that have extensions and no colors (e.g. all image formats) assigned to them?

Before/after screenshots of Gource and one of my projects. Some file colors might look off, but this is because I left duplicate keys in the map.

Before	After

References #104.

P.S. C++ isn't my preferred language, but please let me know if I can do something better. I just explored/hacked on Gource for a few days, and this is the result!

[acaudwell]

I think maybe the way to go is to support a new command line argument (maybe --file-colours) that specifies a file containing the extensions and colours (similar format to the caption file or the custom log file format) rather than have any hard coded mapping of colours:
e.g.

py|#FF00FF
txt|#FFFFFF
go.mod|#00FFFF

If the name contains a dot it could be treated as matching the whole filename instead of the extension. Could potentially also allow including the path as well for giving a colour to a specific file.

There could also be an option --default-file-colour that lets you specify the colour used if the extension isn't in the file colours mapping, otherwise it falls back to using the pseudo randomly assigned colour.

As for languages sharing extensions I'm not sure it can handle that. You need to use a file-colours file appropriate to the language of the project I guess.

[vednoc]

[...] rather than have any hard coded mapping of colours:

While I would love that option, especially if we consider the nature of having hard-coded colors, I think most people would prefer convenience in order to actually use this feature. Over the years, I [personally] saw two modifications (Go, Crystal) and new additions (Zig, Fennel, Mint) to the Linguist project. I wrote a Go program that automates parsing this file, so we'll just need to decide which duplicates to remove (there are slightly over 100 of them).

One way to have both options, I think, would be to make --custom-file-colours option that would first parse the specified file, then have --file-colours which will use the hard-coded ones. That way, we could resolve the 3rd issue because the second option won't insert duplicate keys into the map. Finally, using --default-file-colour would be just as you suggested.

How does that sound? Unless I'm forgetting something, it sounds like that should cover all use-cases.

If the name contains a dot it could be treated as matching the whole filename instead of the extension. Could potentially also allow including the path as well for giving a colour to a specific file.

Got it! I believe I have an idea how to implement that.

[acaudwell]

I'm not sure about that command line argument, maybe --file-colour-mode github.

I think we could distribute the Linguist custom colour file with Gource and load it with the same function as custom colour files.

Could possibly have a command line option that gives a language hint that in this case could resolve ambiguity with file extensions. The file colour file could have an optional last column which is the language? Might be overkill. Not sure how big this issue actually is. Some of the duplicates have the same colour so not actually duplicates.

Could just exclude the duplicates as a first pass.