You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thanks for providing this dotfiles solution. I've used it already since at least 2012 according to my git history, and it has worked flawlessly throughout all the years!
Background
Lately the XDG Base Directory Specification has been gaining quite a steady popularity, even though it's been around for a long time already. The basic idea is to standardize where programs put their files e.g. all config files in a certain directory. The benefits for end users are many, including:
No polluted $HOME/
Can easily grep for only config files in $XDG_CONFIG_HOME
Can decide where to store configurations in more complex setups (multi system setup e.g.)
Easily wipe state by removing $XDG_STATE_HOME or even $XDG_DATA_HOME, but without destorying and configuration files.
The first point is maybe what most end users enjoy the most though.
How
As this project is the one actually setting up dotfiles, this subject becomes a bit meta. But basically the goal is the following: dfm should support looking at
$source_dir/.config/dfm/install or fallback to current
$source_dir/.dfminstall
By allowing the placement of the install file in .config/dfm/, this file will be able to be found (after dfm install) in the default XDG config directory where configuration files should be.
In my own dotfiles repo, I did a PoC erikw/dotfiles@0a0230c and it seems to a rather isolated change. It's just a matter of modifying the 3 identical lines
my $dfm_install = _load_dfminstall("$source_dir/.dfminstall");
to check if $source_dir/.config/dfm/install exist first and use that if found.
So most people will have XDG_CONFIG_DIR being the default value $HOME/.config. But what about if someone actually have set a non-default value; how would .config/dfm/install related to that? I was figuring in that case, this person can in their dotfiles repo do git mv .config/dfm/install .custom-non-default-config-path/dfm/install.
Edit.
~/.backup should probably live in $XDG_DATA_HOME/dfm/backup
The text was updated successfully, but these errors were encountered:
First of all, thanks for providing this dotfiles solution. I've used it already since at least 2012 according to my git history, and it has worked flawlessly throughout all the years!
Background
Lately the XDG Base Directory Specification has been gaining quite a steady popularity, even though it's been around for a long time already. The basic idea is to standardize where programs put their files e.g. all config files in a certain directory. The benefits for end users are many, including:
$XDG_CONFIG_HOME
$XDG_STATE_HOME
or even$XDG_DATA_HOME
, but without destorying and configuration files.The first point is maybe what most end users enjoy the most though.
How
As this project is the one actually setting up dotfiles, this subject becomes a bit meta. But basically the goal is the following: dfm should support looking at
$source_dir/.config/dfm/install
or fallback to current$source_dir/.dfminstall
By allowing the placement of the install file in
.config/dfm/
, this file will be able to be found (afterdfm install
) in the default XDG config directory where configuration files should be.In my own dotfiles repo, I did a PoC erikw/dotfiles@0a0230c and it seems to a rather isolated change. It's just a matter of modifying the 3 identical lines
to check if
$source_dir/.config/dfm/install
exist first and use that if found.So most people will have
XDG_CONFIG_DIR
being the default value$HOME/.config
. But what about if someone actually have set a non-default value; how would.config/dfm/install
related to that? I was figuring in that case, this person can in their dotfiles repo dogit mv .config/dfm/install .custom-non-default-config-path/dfm/install
.Edit.
~/.backup
should probably live in$XDG_DATA_HOME/dfm/backup
The text was updated successfully, but these errors were encountered: