I couldn't figure out why my local changes to the theme colors definition were not being picked up, so I went to the source.
Turned out my yaml file was using some improper fields.

This PR does:

• print a specific warning if in the configcolor.themewas set to custom and nocolors.yaml(orcolors.yml) was found
• print a specific warning if a color theme was found, but the parsing failed, and why it failed.

Contrary to before, if a color file definition exists and it cannot be parsed we immediately switch to the default (plus a warning). The previous logic was hiding format errors if there were other file extensions to try.

Some examples of the output (before regular lsd output):

if color.y(a)ml is found, but contains wrong data

Warning: cannot load custom theme. Theme file format invalid. date: unknown field `days-old`, expected one of `hour-old`, `day-old`, `older` at line 18 column 3.

if color.theme is set to "custom" in the config file, but no color.y(a)ml is present

Warning: cannot load custom theme. Cannot read theme file. No such file or directory (os error 2).

Sidenotes:

• warning output bleed intocargo test.This was already happening withWarning: the 'themes' directory is deprecated, use 'colors.yaml' instead.,I made it slightly worse. Perhaps in general warnings should be behind#[cfg(not(test))]or similar, didn't investigate inprint_erroreither, considered it out of scope.
• imho we should accept a specific extension for color.yml and the others. Iterating over extensions produces subtle bugs like this and there are no particular benefits (if the documentation tells you to create <filename.yml>, you create <filename.yml> - now you also get a warning)

TODO

• Usecargo fmt
• Add necessary tests
• Update default config/theme in README (if applicable)
• Update man page at lsd/doc/lsd.md (if applicable)