3 ms·

> Xdg This is the crap responsible for poluting $HOME. If the user does not configure anything, just use global defaults.

• oguz-ismail 2y ago
  This. Bring back configuration via environment variables
  • throw-the-towel 2y ago
    But why? I think a config file is way easier to understand.
  • cedilla 2y ago
    And when I change a setting in a program, where does it set that environment variable?
    • hulitu 2y ago
      > when I change a setting when.
  • internet_points 2y ago
    Yes, I'd muuuch rather type `FONT_SIZE=7 FONT_FAMILY='DejaVuSans' FONT_WEIGHT=normal BG=black FG=pink FG_HL=blue BG_VISUAL=green THING='noremapsomething<vimscript>' vim` than polluting my home with a single ~/.config directory in which to put all my config files. And if that gets too long to type every time I start vim I can just make an alias and put it in a file and ..oh
  • smittywerben 2y ago
    RegEdit.exe welcomes you with open arms. It even supports multiple endian mixed encoding strings. Clearly it was designed for galactic scale.
• bheadmaster 2y ago
  > This is the crap responsible for poluting $HOME. I think people who wrote software used $HOME for dotfiles way before XDG even existed. > If the user does not configure anything, just use global defaults. And if he does, where do you put the dotfiles? $HOME? XDG defines an cleaner hierarchy.
  • 2mlWQbCK 2y ago
    Clean hierarchy? How do I even guess if some config-file is hidden in ~/.config/ or ~/.local/share? I never figured that out. Looking at the contents of those directories here I can't guess better than a coin-toss. Why not just have a single ~/.dotfiles or something (if hidden files in ~/ is somehow a problem that needs to be solved)?
    • eadmund 2y ago
      > How do I even guess if some config-file is hidden in ~/.config/ or ~/.local/share A config file always belongs in ~/.config/PROGRAM. It never belongs in ~/.local/share/PROGRAM. Data files (e.g. icons) belong in ~/.local/share/PROGRAM. User-specific state (e.g. window positions) belongs in ~/.local/state/PROGRAM. Executables belong in ~/.local/bin/. Cached files (which may be deleted any time for space) belong in ~/.cache. Source: https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ > Why not just have a single ~/.dotfiles or something (if hidden files in ~/ is somehow a problem that needs to be solved)? I believe that the answer is that certain of those directories make sense to share across different hosts (e.g. your laptop and desktop) and others don’t.
      • blooalien 2y ago
        > I believe that the answer is that certain of those directories make sense to share across different hosts (e.g. your laptop and desktop) and others don’t. Also; Some of those directories make sense to flag for backup in your favorite backup software (personal settings, data files, etc), where others (cache) make sense to not waste drive space on backing up.
  • 2y ago
• rnhmjoj 2y ago
  I'm not sure how you came to that conclusion, but you got everything completely wrong. First of all, writing state and configuration files in the home directory, without any well thought out structure, has been a common practice since UNIX existed, XDG did not even exist then. Precisely because this lazy practice causes all sorts of problems, the cross-desktop group (XDG) came up with a standard called the "base directory specification"[1] which proposes to divide applications files into configuration, data, caches and are supposed to be stored in subdirectories named after the application in $XDG_CONFIG_HOME ($HOME/.config if unsed), $XDG_DATA_HOME ($HOME/.local/share if unset), $XDG_CACHE_HOME ($HOME/.cache if unset), respectively. [1]: https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/