5 ms·

> For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Spe

> For a program that's minimal it sure takes a long time to start up, the standard C-p and C-n bindings don't work, it doesn't follow the XDG Base Directory Specification and just pollutes my $HOME directory. This drives me mad, I believe Ollama and Claude Code also do this. Seems to be rife in the LLM world. IMO there's no excuse for new software sticking dotfiles in my homedir in 2026.

msdz 2mo ago
> IMO there's no excuse for new software sticking dotfiles in my homedir in 2026. Agreed, and also, tinfoil hat time: I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?
- Defletter 2mo ago
  I'd also add that convenient recursive folder creation was only added relatively recent for many languages (eg: "std::filesystem::create_directories" was only added in C++17). And since "~/" is pretty much guaranteed to exist, the fewer folders you needed to create, the less code you had to write.
- gwerbin 2mo ago
  I think underuse/under-marketing of XDG_STATE_HOME is a contributing factor. Developers see XDG_DATA_HOME and XDG_CONFIG_HOME and, following the spec, don't feel like their app's files conform to either definition. It's easier to just not bother. Neovim now uses all 3 and it's very nice IMO.
mr_mitm 2mo ago
My impression is that it's the NodeJS, Go and Rust communities that don't care about XDG. This 11 year old, open issue is very symptomatic of this IMHO: https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/cargo/issues/1734
- Philpax 2mo ago
  In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG. .cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
  - anonym29 2mo ago
    [flagged]
  - gcr 2mo ago
    why can’t it be undone? for new installations going forward, why not put the folder in XDG_CONFIG_DIR and an optional symlink from ~/.cargo that can be opted in
- ptman 2mo ago
  Go isn't perfect, but $GOPATH isn't really used that much anymore. There's a bunch of stuff in ~/.config/ and ~/.cache/
  - mr_mitm 2mo ago
    Go creates `~/go` by default. It's not even hidden. Unfortunately, saying it's not really used that much doesn't help with this.
- olowe 2mo ago
  Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir. [1]: https://pkg.go.dev/os#UserConfigDir https://pkg.go.dev/os#UserConfigDir
  - maleldil 2mo ago
    > On Darwin, it returns $HOME/Library/Application Support Which is not the behaviour most people would think is sensible, especially for CLI programs.
deadbunny 2mo ago
i raised a bug for this on the pi repo. it was immediately triaged into `wont do`.
the_mitsuhiko 2mo ago
The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”. I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle. (Disclaimer: I work on Pi but I dislike XDG in all settings)
- dust42 2mo ago
  As a user I still prefer .pi right there in my home directory.
- oblio 2mo ago
  Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%. I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views. And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible. Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
  - gwerbin 2mo ago
    I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
    - nasduia 2mo ago
      it's certainly easier to keep a single directory under version control and share between Linux and macOS

msdz 2mo ago

> IMO there's no excuse for new software sticking dotfiles in my homedir in 2026. Agreed, and also, tinfoil hat time: I believe they opt for this so that state and config files don’t need to be distinguished (it all goes into ~/.appname the same). It’s still not an excuse, but maybe laziness is the reason?

Defletter 2mo ago
I'd also add that convenient recursive folder creation was only added relatively recent for many languages (eg: "std::filesystem::create_directories" was only added in C++17). And since "~/" is pretty much guaranteed to exist, the fewer folders you needed to create, the less code you had to write.
gwerbin 2mo ago
I think underuse/under-marketing of XDG_STATE_HOME is a contributing factor. Developers see XDG_DATA_HOME and XDG_CONFIG_HOME and, following the spec, don't feel like their app's files conform to either definition. It's easier to just not bother. Neovim now uses all 3 and it's very nice IMO.

mr_mitm 2mo ago

My impression is that it's the NodeJS, Go and Rust communities that don't care about XDG. This 11 year old, open issue is very symptomatic of this IMHO: https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/cargo/issues/1734

Philpax 2mo ago
In my experience, the Rust community very much cares - it is a struggle to find a modern Rust application of any popularity that does not abide by XDG. .cargo's placement is a historical mistake that can't be undone now, but ecosystem participants are generally good participants.
- anonym29 2mo ago
  [flagged]
- gcr 2mo ago
  why can’t it be undone? for new installations going forward, why not put the folder in XDG_CONFIG_DIR and an optional symlink from ~/.cargo that can be opted in
ptman 2mo ago
Go isn't perfect, but $GOPATH isn't really used that much anymore. There's a bunch of stuff in ~/.config/ and ~/.cache/
- mr_mitm 2mo ago
  Go creates `~/go` by default. It's not even hidden. Unfortunately, saying it's not really used that much doesn't help with this.
olowe 2mo ago
Not sure about use in the Go community at large but Go introduced os.UserConfigDir[1] which is portable across Windows, macOS, Plan 9 and Linux/BSD as per XDG back in 2019. Also CacheDir. [1]: https://pkg.go.dev/os#UserConfigDir https://pkg.go.dev/os#UserConfigDir
- maleldil 2mo ago
  > On Darwin, it returns $HOME/Library/Application Support Which is not the behaviour most people would think is sensible, especially for CLI programs.

deadbunny 2mo ago

i raised a bug for this on the pi repo. it was immediately triaged into `wont do`.

the_mitsuhiko 2mo ago

The problem with the XDG spec is that it now forces you to have different paths on different platforms. It just increases the complexity and at the end of the day unless all software adheres to it, you still end up with a “polluted HOME”. I’m not a fan of config directories being in different locations on different platforms because it’s now one extra thing everyone needs to handle. (Disclaimer: I work on Pi but I dislike XDG in all settings)

dust42 2mo ago
As a user I still prefer .pi right there in my home directory.
oblio 2mo ago
Platform standards already require things to be in different locations compared to *NIX dotfiles and dotdirectories - for example Windows %APPDATA%. I find it a bit shocking that someone working on an agent harness can't be bothered to spend 5 minutes to research this with the help of an LLM and holds such rigid and uninformed views. And if you don't want to respect platform standards, just respect XDG on all platforms. The .app solution is the laziest one possible. Just follow XDG everywhere and create .config/app & co everywhere, at least that way there's a chance more apps end up in subfolders instead of ending up with a million folders in the user directory on BOTH Linux and non-Linux.
- gwerbin 2mo ago
  I suspect some people are out there who actually like the single directory style. Obviously it's easier for the software developer, but I suspect some users like it too because everything's all in one place. It's very likely that Mario is one of those people.
  - nasduia 2mo ago
    it's certainly easier to keep a single directory under version control and share between Linux and macOS