support for theme.yml file

[PThorpe92]

This is the base of what we will need for a config.yml, which will build on top of this. This includes the changes from #744 as it was necessary in order to serialize the Style struct.

[hasecilu]

Hello, is it planned that config.yml file takes care of custom icons? As of now if a user requieres to add a new icon or change one that conflicts with an existing one it needs to compile from source, to get latest changes need to be rebased from time to time, so having overrides via config file could be awesome.

[PThorpe92]

Hello, is it planned that config.yml file takes care of custom icons? As of now if a user requieres to add a new icon or change one that conflicts with an existing one it needs to compile from source, to get latest changes need to be rebased from time to time, so having overrides via config file could be awesome.

Yes! that is the plan, and I even have a local branch with progress made on it. As it happens, there are lots of significant changes happening in the codebase right now (clap, major dependency changes), so I didn't want to push it and try to do too much at once.
But custom icons is actually the first feature that the config file will support, and will be included in the PR introducing it 👍

That has been a very common request, so it's on top of my list

[cafkafk]

There seems to be a failing test (sorry for noise if you're still working on this, just saw review was requested so didn't wanna let it hang in case!)

[MartinFillon]

Could you clarify some of my concerns please ?

[MartinFillon]

I was wondering how you felt about, as we have the env var, the default value, adding also a command line argument such as --theme or --config as this is kinda a standard ?

[PThorpe92]

note: i have more local changes now so further review can wait till prob tomorrow

I am certainly open to the command line arg. My thought was that XDG_CONFIG_HOME was pretty standard, with the option of giving an env var for fallback if someone wanted to go somewhere else.

I would really like to get clap merged because it seems like this arg parser is just cursed lately 💀

[MartinFillon]

I would really like to get clap merged because it seems like this arg parser is just cursed lately 💀

same especially since #832 but we waiting on @cafkafk

[gierens]

The commit I added fixes the nocolor/color=never option.

The gist of it is, that when UseColour never uses NoFileStyle and UiStyles::plain, and during unwrapping in Theme.colour_file the NoFileStyle.get_style returns None which makes the colour_file fall back to the UiStyles. Since UiStyles::plain simply calls default the default colors remain.

By actually setting all colors to the default style in UiStyles::plain this is mitigated. And since it is only called in this case, this doesn't break anything either.

[hasecilu]

Hi, I can't provide a technical review but I tested this branch, the config file provides a very extensive list of options which is awesome because enable users to tweak icons without hardcoding them, very handy. I understand that a lot of extensions on my icon PR are very niche so this is very helpful.

Just 2 more notes:

• It could be possible to specify the color of the icons per extension? An example of this behaviour is found on https://github.com/nvim-tree/nvim-web-devicons
• It could be possible override the icons in a group basis? As in impl Icons {}; For example changing on const GIT: char = '\u{f1d3}'; //   -> 󰊢

Very nice job, thanks!

Example on LazyVim that uses Neotree that uses nvim-web-devicons

[PThorpe92]

I think @gierens had an implementation of changing the icon colors in a previous PR if I'm not mistaken?

[gierens]

Point 1 (extension-based icon color overrides):
Yeah, PR #903 was in reaction to discussion #891 which basically asked for the ability to set the color of the icon column more or less. So this PR sets all icons to the same color.

While that differs from what is asked here, I think overriding the icon colors of individual extensions or filenames should be fairly straight forward from what I've already added here. The only thing I'm a little worried about is how adding a color string could affect the hashmap performance. I can take a look at it later and experiment around a bit.

Point 2 (group based icon overrides):
This one is little tricky I think for multiple reasons.

First of all this would need a more extesive design as to what the behaviour actually should be, how this should mix with the extension overrides and what takes priority ...

Second, an implementation might have to touch the exact part of the code I was trying to avoid meddling with here: impl Icons defines a bunch of constants that are then used in the DIRECTORY/FILENAME/EXTENSION_ICONS which are phf_maps meaning they are built at compile time.

Third, I'm not sure how much value this adds for the user in comparison to the complexity it might introduce. The current proposal here is imho quite elegant because it is extension/filename-based and thus completely circumvents the maps in the icon module which also makes it quite intuitive because the user has fine-grained control and does not need to know about how eza internally maps Icons to DIRECTORY/FILENAME/EXTENSION_ICONS. Sure, some stuff is left on the table at the moment like individualizing the directory icons but I think this is a good trade-off for the time being.

TLDR:
I think the extension-based icon color overrides is fairly doable and I'm gonna give that a shot later, but the group-based icon overrides introduces too much complexity and is thus out of the scope of this already large PR.

[hasecilu]

I think the extension-based icon color overrides is fairly doable and I'm gonna give that a shot later, but the group-based icon overrides introduces too much complexity and is thus out of the scope of this already large PR.

Thanks for the explanation, and sure for point 2, the worst case would be that user needs to repeat a few times the same glyph, is not a big deal, it's preferable that both the code and the config file remains simple.

[gierens]

@hasecilu I added a style field to icon overrides in the config file:

@PThorpe92 I first just wanted to add a color to icons but then thought, why not the whole Style. Then I got annoyed by specifying all Style fields in the config file and one thing lead to another ... Long story short, I wrote an "override" layer in the config module for the entire UiStyles struct. Meaning now every field in the config file is optional and users only have to specify the fields they wanna change and not this whole 500 plus line bloat.

This works by defining a mirror for every struct in and including UiStyles, starting with UiStylesOverride down to StyleOverride, and then defining a custom trait FromOverride which transforms those back to the normal ones basically overriding the defaults where requested. So ThemeConfig.to_theme deserializes into UiStylesOverride and this is then turned into the usual UiStyles.

While this bloats the config module a little, I think we rather wanna have bloat there than in the config file itself.

[hasecilu]

@hasecilu I added a style field to icon overrides in the config file:

Looks good, testing was ok

[PThorpe92]

@cafkafk this should be all set

[hasecilu]

Hi again, I was changing some colors when I noticed that having a good config file resets the foreground color of the filename given by its type (document, video, image, source code, etc). When something fails (I used "Reda" as color) filename fg color is preserved, is this the desired behavior or fg color should be maintained?

EDIT: Tested with files that were already on eza and seems to work as expected with all files except "source code" files, my testing branch

this branch

my branch

[gierens]

@hasecilu I'm not certain I fully understand what your are referring to, but I'll do my best to answer. So, I believe you are mentioning two problems:

1. Theming in case of a bad config file:
The config file is simply deserialized using serde_yaml at the moment, and in case it cannot be parsed properly I think the code falls back to default (or theming configured by other means like environment variables).

2. Filename colors differing from icon colors:
The icons part of the config file only affects the style of the icons not the filename next to it.

Theoretically I could also add the option to configure the filename color next to the icon color for some extension or filename. I thought about adding this functionality already.

[hasecilu]

@hasecilu I'm not certain I fully understand what your are referring to...

What I wanted to say is: it seems that something is conflicting in the filenames color of some types of file (at least the source code).

From the first picture

• First command, (good config file): I would expect that also the c and cpp files to be colored as in the source code group, i.e. they should be also yellow, bad. Somehow the executable, audio and video files preserve their filename fg color + adds icon color, good.

    "c"          => FileType::Source, // C/C++
    "cpp"        => FileType::Source, // C/C++

• Second command: I forced a error in the config file and settings fallback to defaults which demonstrates that the source code group has indeed a setting to show the filenames fg color in yellow, so: why the introduction of the config file reset the fg color?

I don't think this is the expected behavior because other types of files preserve their filename fg color.
From the second image you can see some files to be source code with yellow color, but using the config file reset the color.

2. Filename colors differing from icon colors:
The icons part of the config file only affects the style of the icons not the filename next to it.

Agree

[gierens]

@hasecilu Sorry, but I'm still a little confused maybe because it's getting late and my brain is not working at full capacity anymore and the second screenshot being a little full.

Could you provide a minimal example? So a config file with just the necessary configuration and a directory with just the necessary files (so ideally just a few lines and files in both cases) that trigger that unexpected behavior.

[newo-2001]

Correct me if I'm wrong @hasecilu but I believe you are concerned about this example:

The first command here is run with the default configuration and the second is run using the configuration below:

icons:
  extensions:
    c: { style: { foreground: Red } }

I believe @hasecilu expects the foreground color of the filename in the output of the second command to remain yellow.

[hasecilu]

Could you provide a minimal example? So a config file with just the necessary configuration and a directory with just the necessary files (so ideally just a few lines and files in both cases) that trigger that unexpected behavior.

0. Compile this branch
1. Create test files

mkdir testing && cd testing
touch f.flac g.gpg lib.o main.c main.cpp main.py p.png m.mp4 s.svg z.zip && eza --icons

2. Create theme.yml file that changes color of test files' icons

icons:
  extensions:
    c: { style: { foreground: Red } }
    cpp: { style: { foreground: White } }
    flac: { style: { foreground: Black } }
    gpg: { style: { foreground: Blue } }
    mp4: { style: { foreground: Cyan } }
    o: { style: { foreground: Magenta } }
    png: { style: { foreground: Red } }
    py: { style: { foreground: Green } }
    svg: { style: { foreground: Yellow } }
    tmp: { style: { foreground: Blue } }
    zip: { style: { foreground: Magenta } }

3. Execute next commands to see how filenames color is changed when it should remain the same. (no need to break the config file, just use another dir).

echo -e "This is the default behaviour\n" && EZA_CONFIG_DIR=.. eza --icons
echo -e "This is the attempt to change icon color, filenames color is not always preserved\n" && EZA_CONFIG_DIR=. eza --icons

I believe @hasecilu expects the foreground color of the filename in the output of the second command to remain yellow.

Exactly

[gierens]

Sorry for the late reply guys, and big thanks @newo-2001 and @hasecilu for pointing out the issue!

Now I see it, too, and also where I messed up. I've got a rough idea how to fix it.

[PThorpe92]

@gierens I finally had a few mins of free time, I looked at this and I wasn't able to locate where the issue is this time.

[gierens]

After 1.5 hours and more black magic I think I've fixed it. Basically the FromOverride trait now pushes the defaults down the chain rather then ignoring them.

@gierens I finally had a few mins of free time, I looked at this and I wasn't able to locate where the issue is this time.

@PThorpe92 No worries, this was neither easy to spot nor trivial to solve. My head hurts 😵 haha

[gierens]

@PThorpe92 I have one final idea assuming this works and no more repairs are required:

Since the icon overrides are filename- or extension-based, we could make a general filename style override out of this where users can edit both the filename style and the icon style.

What do you think?