Let users define custom icons and color for files on the config file

[hasecilu]

• PR Description

Yet another icon-related PR

• Implementation on config file for user defined file icons and colors.
• Fix for some file icon mappings.

I use eza, nvim-wewb-devicons and lazygit; the first ones already let user to override icons and colors via a config file, so with this change I can customize based on filenames and file extensions.

Before	After

gui:
  customIcons:
    filenames:
      "CONTRIBUTING.md": { icon: "\uede2", color: "#FEDDEF" }
      "HACKING.md": { icon: "\uede2", color: "#FEDDEF" }
    extensions:
      ".cat":
        icon: "\U000f011b"
        color: "#BC4009"
      ".dog":
        icon: "\U000f0a43"
        color: "#B6977E"

---

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

I can't say that I find this feature super important myself, but it seems that it's easy enough to add, so why not.

We need to solve the config generation problem first though, see below.

[stefanhaller]

Hm, this doesn't make sense. We have a generator that auto-generates this section; it has code that skips any objects that have no fields, or any arrays that have no items. What happens here though is that we have an object that has two fields, both of which are arrays that have no items. We somehow need to skip that too, but it's not immediately obvious how.

Cc: @karimkhaleel in case you have any idea.

On the other hand, I also have to say that I find it unfortunate that we skip empty arrays in the first place. It would be nice if we could include them in the docs somehow, indicating what kind of objects can go into the array and what fields they have. I haven't thought much about how exactly we might achieve that, though (or what exactly it would look like).

[stefanhaller]

I opened #4413 which should improve this a bit.

[karimkhaleel]

Adding in empty arrays/objects to the generated config seems like a good solution to me. An empty array/object can still provide useful documentation.

[stefanhaller]

@hasecilu #4413 has been merged, so please rebase on master, so that we can work from there. Also feel free to squash the fixups that we have so far.

[stefanhaller]

@karimkhaleel I find it interesting that we have this description both on the CustomIconsConfig definition above, and here on the $ref. I suppose this one here isn't needed? Same problem with the CommitLengthConfig struct, and probably others. Must have come in with 30e9bf8.

It doesn't seem to be a problem in practice, but if you feel bored, you might look into whether this is our fault or invopop's. Shouldn't block this PR, of course.

[stefanhaller]

@hasecilu Thanks. I pushed two more small fixups, I'm happy with this now and would be ready to merge if you want to have a last look at those.

[hasecilu]

Changes look good, better to have those descriptions; the new lines were for markdownlint rule MD031.

---

Just a minor thing I noticed when squashing the !fixup commits. Should the "Apply fixup commits" commands add a co-author when the fixup was made by a person different of the one made the original commit? Of course is easily fixable with "Add co-author" function. GitHub adds the co-author string automatically on its web interface when squashing and when applying a maintainer's suggestion, so it could be a nice behaviour to mimic.

[stefanhaller]

the new lines were for markdownlint rule MD031.

Ah, ok. Happy to put them back in then (1eb00d8). This shows that it's always a good idea to commit independent things in separate commits, with commit messages explaining why you are making the change. Something to keep in mind for next time. 😉

Should the "Apply fixup commits" commands add a co-author when the fixup was made by a person different of the one made the original commit?

Yeah, maybe. Personally I don't care about getting my fixups attributed with co-author lines. When I push fixups to a contributor's branch I do it just to save time; I might as well have told them in a comment what I would like to see changed, and then they would have made the change themselves. But whatever, it might be a good idea in general, but I have the feeling it should be behind an opt-in config (not really sure).