Great idea! Do you think we should support the option for per-repo config files, too (I'm leaning towards no, but just want to put it out there)?

I did something similar in my (unfinished 🤣) project repofetch in case you want to reference something.

What format do you think it should be? I like YAML for human-editable files, but TOML, INI, and JSON also have some pros and cons. Or do we go the extra mile and support multiple formats?
Edit: nevermind, I think this question is answered by your example path *.conf 🤣

A cli option to print the location of the config file can also be useful, as well as an option to provide a different path to the config file.

Great idea!

Thanks 😊

What format do you think it should be?

The format is still up for discussion, as you mentioned YAML and TOML seem more human-readible/editable. I like TOML because it allows for sections (maybe YAML does too 🤔), which makes it easier to organize/parse the entries by category, smth like:

[general]
spacing = 2
padding = 0
separator = "->"

[palette]
glyph = "o"

[info]
size= "🖴"

A cli option to print the location of the config file can also be useful, as well as an option to provide a different path to the config file.

Good idea, your second suggestion would be very useful 👍

🤔 Yeah in YAML I think it would just be

general:
  spacing: 2
  padding: 0
  # etc.

Now I'm leaning more towards TOML, since it provides the user with more freedom in how they choose to format.

# they can do this
[general]
spacing = 2

# or this
general = { spacing = 2 }

We might want to get some metrics to figure out the most popular format, maybe even just by searching config.toml, *rc.yaml, etc. on GitHub (does GitHub allow searching partial filenames?).

Although one other config format I've seen tools use is basically to make a 1:1 of the CLI without any nesting, where basically --option=* in the CLI becomes option=* in the config file (so pretty much INI format). In that format, ours would look like this

# flag in CLI
email=true
# option in CLI
true-color=never

IMO regardless of the format, it would be great to make it possible for a user to understand the config just by using onefetch, without needing to go on the web to reference any docs. I guess we can add it to a man page, but we can also generate a default config with all options for the user to edit, or have a CLI tool like onefetch config list|get|set|edit, or something else.

🤔 Now that I think about it, implementing serde::Deserialize on the Config struct would accomplish a lot of the necessary work. Then it's pretty easy to choose which format to support, or even support multiple formats.

For config paths, there's dirs-next and directories-next, but it looks like the original crates (not -next versions) are once again actively developed.

Good point!
In that case we may need to extend the Config struct by adding more CLI flags for customization, e.g. :

• The glyph to use for the separator (use "->" instead of ":")
• Which glyph to use for the palette (use "●" instead of " ")

But we can already start with what we have and add more options later on.

I needed to double-check since it's been a while since I've used this Rust feature, but destructuring could make this really easy to implement. Might be worth making this a hacktoberfest issue 🎃

Hello! I'd like to take this issue as part of Hacktoberfest 🙂

One solution for making the config easily understandable for the user would be to generate the config if it doesn't exist, populating it with default options, and make sure it has comments that help understanding. Then the simplest option to reset the config to defaults would be just to delete/move the config file, as it would be recreated on the next startup.

Just want to throw this out there: If mehcode/config-rs#328 is implemented, then config-rs could be a perfect library for this issue, using a config file and clap as config sources.

Just want to mention this, even though I'm not sure if it's a good idea.

Assuming onefetch is always a Git repo tool (Maybe not?: #860), we could potentially take advantage of git configs. For a user, example usage would be like this:

git config --global onefetch.image-path /home/me/Pictures/profile-pic.png
cd my-repo
git config --local onefetch.image-path assets/logo.png
# onefetch now "magically" shows the logo when run my-repo, and the profile pic in any other repo

Reviewing old issues in this project...

Yet another format, and possibly the easiest to implement, would be a simple options list. If you look at the Ruby ecosystem, with files like .rspec and .yardopts, configuration files are often just a list of CLI arguments.

--image profile-pic.png
--exclude dist
--disabled-fields churn

We shouldn't have to do much more than split this file into a &[&str] and pass it to clap. Just split on newlines and spaces, preserving spaces inside "quotes".