Proposal: switch to TOML config files instead of using environment variables about zoxide HOT 2 CLOSED

Those are fair arguments. I don't think the development cost of supporting TOML and environment variables is justifiable at the moment, so I'm going to put this one on the backburner for now.

from zoxide.

This might be a little less coherent than usual, because as I was about to
submit my original rebuttal, the power went out (and I was drafting in GitHub's
textbox... lesson learned).

I strongly recommend against dropping environment variables altogether. Despite
it being a "fairly limited use case," it is one I rely on when testing. It would
extremely inconvenient to "keep an editor open with a temporary config file and
change it as desired."

Take, for example, if we were to move to TOML-only right this moment: once the
_ZO_FZF_ARGS PR is merged (assuming it changes from an env var to the expected
configuration file), I would want to decrease the height of fzf with its
--height flag. If we drop environment variables altogether, this would look
like the following:

1. nvim ~/.config/zoxide/config
2. edit value
3. save file
4. zoxide query -i
5. decide if I'm satisfied; else, go back to 2

With the environment variable, I would only need to 1) _ZO_FZF_ARGS="--height 20%" zoxide query -i, and 2) decide if I'm satisfied; if not, press the up arrow and
change 20% to something else.

I think we should be careful with adding features that will "result in a slight
slowdown," no matter how "slight" that turns out to be. As the README stands
today, it claims that zoxide is a "blazing fast alternative to cd," which
implies (to me) that we value speed above all else. If we start adding features
under the guise of a "slight" performance impact, they will add up to the point
where they are no longer just "slight" differences.

We could compromise with feature flags: toml for a configuration file and
env for environment variables. Ideally, both would be allowed at the same
time, with environment variables taking precedence over the config file (in
order to support my usecase of testing and overriding on a per-shell basis).

Overall, I'm not opposed to adding a configuration file because you propose
valid points, such as being cross-shell compatible and having richer data
structures, as long as we do not drop environment variables.

(As an aside, to rebuke your "colon in ignored path" example: it's on the user
to escape the colon, just like in the system-wide PATH. If, due to not escaping
the colon, it results in unexpected ignores, it is most definitely not our
fault.)

from zoxide.