Config file?

[Omnikron13]

I think there should really be a config file for this, to set up various defaults and such. Even the colours and what have you that can be tweaked with environment variables, it seems it would surely be better to really have in a config file doesn't it?

I've hacked my way to getting it to behave how I'd like with fish abbreviations and such like, but it seeems weirdly missing like $XDG_CONFIG_HOME/eza.conf (or perhaps even a folder under $XDG_CONFIG_HOME if people might want to have colour/icon themes and such?)

Shouldn't really be that tricky to implement imo, it's more what kind of file format, what options, etc. people would favour?

[PThorpe92]

This is currently a work in progress, with the first step (a theme.yml file replacing the EXA_COLORS environment variable) PR just being hung up on testing issues.

This is technically a duplicate of #139 but I'll leave it open for discussion on what everyone would like to see feature wise for the eventual config file and ideally so we can get a few theme contributions. I'd really like to be able to offer a handful of pre-made themes to choose from when #840 can get merged. 👍

[PThorpe92]

Looks like this will get merged here pretty soon, and with custom icon support both thanks to @gierens 🚀 🚀

[CouldBeThis]

I wanted a config file for ages to replace my collection of long shell aliases. A couple of times went looking around in the documentation, repo, online etc trying to find out how to do it.

@PThorpe92 I see #840 which from what I can see is mostly about colors, with an eye to expanding later. I will patiently wait/hope for all the options to be included eventually. And appreciating eza and contributors meanwhile.

I read #139 and while initially wasn't sure if there is really a benefit to config file vs shell alias I found it convincing that there is. Personally I just find things easier to read with linebreaks, comments and divided up into multiple files. Since opinions were solicited here:

• I saw formats yaml and toml mentioned and support for theme.yml file #840 is using yaml. Just please don't make is json or some other format that doesn't allow for commenting.

• Loading a specific config file when running would be great. e.g. eza -c ~/.config/eza/alternateconfig.yaml

  • With arguments/config files having clear order of precedents. I think left-to-right is standard

• I personally find it really helpful when cli tool facilitate the creation of a config file

  • My feeling for eza is that generating one by an argument on request is probably better than dropping one in the $XDG_CONFIG_HOME or some system directory by default at install time. Because it is having a lot of development. And I have seen before where there is some sort of compatibility issue between config files for different versions.
  • Come to think of it (and maybe someone else already did), I wonder if it would make sense to consider different versions and future addition/removal/change of features? You don't want eza to die because you bring your dotfiles in from a different system that is a few versions ahead and the config file has something the current version doesn't recognize. Perhaps it would be best to silently skip any unrecognized entries unless a strict/verbose mode is requested by the user? Which I guess could be either via the cli or in the config file itself.
  • Opinions differ, but my preference is that either by default, or on the website, or somewhere, there is a config file available with all/most of the available options rather than just a few. Easier to delete than search around copy/pasting.
  • Opinions differ, but my preference is that the default config has comments explaining whatever options it does include so you don't have to spend time cross referencing a different document.
  • Both the above subject to maintainability. It would be tedious for the devs to have to manually update with each release.

[Omnikron13]

• I personally find it really helpful when cli tool facilitate the creation of a config file

In the hobby project I've been mucking around with lately, I'm going with a strategy of embedding a commented YAML config file as the source of default values. You can then just handle that the same way as the rest of the config file hierarchy, it centralises the default configuration, users can easily find it in one place in the project repo, and you can very easily add a few lines of code that will spit a copy out for end users.

[PThorpe92]

@CouldBeThis

Awesome, those are all helpful points!

I believe we will be sticking with yaml. I personally cannot stand JSON for a configuration language, I deal with too much of it at work as it is 😅

I also think it's a good idea to be able to load a specific config as a command line argument, and I'd like to have another one that dumps the default config to stdout or a specified location. And I agree the default one should include good comments 👍
I don't really like dumping one at XDG_HOME | XDG_CONFIG, but I think its reasonable to check there for an existing one (if EZA_CONFIG_DIR isn't set, before falling back to the normal configuration previously done from ENV variables.