fix: make EZA_COLORS=reset clear built-in styles

[martenlienen]

Description

This PR fixes EZA_COLORS=reset to actually do what the documentation says, i.e. reset eza's styles to plain and disabling the default theme. At the moment, resetting the colors has no effect.

How Has This Been Tested?

I have added CLI tests to verify the correct coloring given EZA_COLORS=reset and EZA_COLORS=reset:... and the interaction with LS_COLORS.

Fixes #731.

[namurphy]

Thank you for working on this! I'm looking forward to this being merged.

I compiled this branch to try it out. I set EZA_COLORS=reset and removed theme.yml, and all built-in styles were successfully cleared when I ran eza. ✅

When I created a blank theme file with touch ~/.config/eza/theme.yml, the styles were no longer cleared (except for normal filenames).

Could this PR be extended to make EZA_COLORS=reset clear default styles even when theme.yml is present? 🤔 Thank you again!

[martenlienen]

I think mixing theme.yml and EZA_COLORS would be confusing, when theme.yml seemingly intends to avoid use of the environment variable. Instead, I believe it would be better if theme.yml would get its own reset: true attribute to specify if it should inherit from the default or the plain style, but that should go into a separate pull request.

[namurphy]

I think mixing theme.yml and EZA_COLORS would be confusing, when theme.yml seemingly intends to avoid use of the environment variable. Instead, I believe it would be better if theme.yml would get its own reset: true attribute to specify if it should inherit from the default or the plain style, but that should go into a separate pull request.

Agreed that theme.yml should have its own configuration variable! I create #1724 for this suggestion.

Since EZA_COLORS takes precedence over the theme file, should EZA_COLORS=reset also clear the styles defined in theme.yml? 🤔 When I tested this branch, even an empty theme.yml made it so that setting EZA_COLORS=reset didn't work, meaning that the theme file took precedence over EZA_COLORS.

Thank you again for working on this!

[martenlienen]

That precedence problem is also a separate issue from this one I believe. I deliberately do not use the theme file, because I do not want eza to have to read a file from disk every time I use it.

[namurphy]

Since there will still be the separate issue that setting EZA_COLORS=reset will not do anything when a theme.yml is in use, adding this caveat to the documentation would likely help prevent confusion by users who have a theme.yml and want to do this reset.

Since #1724 proposes adding a configuration variable within theme.yml to perform this reset, I'll add a note there to update the documentation near the discussion about EZA_COLORS=reset.

Thank you again for submitting this!

[namurphy]

Suggested change

	So setting `EZA_COLORS="reset:*.txt=31"` will highlight only text files in addition to any styles in `LS_COLORS`; setting `EZA_COLORS="reset"` disables eza's built\-ins completely.
	So setting `EZA_COLORS="reset:*.txt=31"` will highlight only text files in addition to any styles in `LS_COLORS`; setting `EZA_COLORS="reset"` disables eza's built\-ins completely.
	However, setting `EZA_COLORS="reset"` is not yet supported when a configuration file (`theme.yml`) is in use.

[namurphy]

Suggested change

	So setting `EZA_COLORS="reset:*.txt=31"` will highlight only text files in addition to any styles in `LS_COLORS`; setting `EZA_COLORS="reset"` disables eza's built-ins completely.
	So setting `EZA_COLORS="reset:*.txt=31"` will highlight only text files in addition to any styles in `LS_COLORS`; setting `EZA_COLORS="reset"` disables eza's built-ins completely.
	However, setting `EZA_COLORS="reset"` is not yet supported when a configuration file (`theme.yml`) is in use.