> Author here; I was under the impression the quote from the Vim issue tracker in §3.1 was a good cornerstone for the article, which is that accepting and implementing an existing standard—however hard it might be for developers now—is good for users in the long term, because it makes life easier for them.

In my opinion, ~/.something is easier for me as a user than using the various XDG directories. But in practice, I really don't care what scheme an application uses.

The XDG spec gives YOU as the user CONTROL to get it like how you want it to be. That is why you can set the $XDG* variables, so that the software listens to your wishes. Without XDG adherence, software packages just piss all over the place, wherever they like to.

There are programs that even manage to create multiple dirs, like .something1/ and .something2/. Some other programs are even worse and put files just into $HOME. Good luck with backups.

With XDG adherence applications might comply and put files scattered around the various XDG directories. Before XDG, applications that pissed all over my $HOME were rare, applications generally played nice and kept only on dot file or directory.

Backups are even harder now because I have to cherry pick what to backup from even more places. I don't backup all of $HOME because it's loaded with junk I don't want to waste backup space on.

As another user, I do care, and I dislike the XDG directories. ~/.local/share/foo in particular is obnoxiously longer than ~/.foo, and the existence of the XDG spec means that if I don’t know where a program stores its files, I now have to check three possible locations (~/.foo, ~/.config/foo, ~/.local/share/foo).

Now I have to scan whenever ~/.foo/tmp, ~/.foo/cache, ~/.foo/cef/Cache or whatever hell has the useless uncompressible, duplicated and always changing data to exclude from backups and synchronization, for every program that fills random dotdirectories.

I find it easier to exclude all .* from the rsync I do to synchronize documents/data etc, and exclusively manage the dotfiles through another program, homeshick, where instead of making exclusions, I make explicit inclusions. The config files I care about are far, far fewer in numbers than the random crap programs spew in dot folders.

I like the XDG specs, but even programs that pretend to follow it don't follow it. CMUS, a music player, moved into ~/.config.. moved everything, including files that belong to .cache and .local/state. Google Chrome has 999 mb worth of files in its .config folder on my computer. The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.

> The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.

This is a great point, honestly. XDG actually does specify where things are supposed to go, and distinguishes between config, cache, state, and strictly-user files, but devs don't respect that hierarchy, either.

Apps dumping cache/state into ~/.config/myapp/ is still better than ~/.myapp in the vast majority of situations. I can still usually afford to sync / strongly back up ~/.config even with a few bad apples barfing heavyweight cache/data there (and I can always use ignore rules), while syncing all of $HOME is just a nonstarter.

> I can still usually afford to [backup huge caches incorrectly placed into ~/.config], while syncing all of $HOME is just a nonstarter.

I completely fail to understand this viewpoint. The non-config files that I intentionally put into $HOME are infinitely more valuable than anything I would want to backup from .config.

I have hundreds of gigabytes in non-hidden sub-directories of $HOME, such as all my family photos, all my health-related documents, all my email, and so on -- and they are backed-up every single day.

Why is backing up your actual files in $HOME a non-starter? What makes your .config more valuable than everything else in your $HOME?

As another user, I find it infuriating that 95% of all applications I run respect XDG and go into ~/.config (where I have hundreds of folders), but a handful or two do not and litter in my home folder.

If only the last stubborn applications would comply, I would have just 1 place to look for config, and one place to wipe caches.

Plenty of apps which use .config use it for everything, caches included. The percentage of apps which fully respect the XDG spec is much lower than the percentage that use the XDG config dir. And this is to be expected - changing the default config dir is one thing, changing your code to put different kinds of files in different places is much more work.

The point is that you could use those locations if you wanted, but many apps don’t make it easy to make them respect your desired config.

Not really - since XDG decided to go for non-hidden files inside the XDG dirs. So you can't just set your XDG config dir to be your home dir, since all the app config folders will be non-hidden folders in your home dir. And setting up multiple XDG dirs to point to the same dir will probably cause even more havoc, if apps use the same file name with different meanings in different XDG dirs.

Many apps that claim to respect XDG…don't respect XDG fully and mix executables, config, temporary files, and persistent files in some combination of the spread of XDG directories.

The position is clear, but I don't think it's a valid position. If I, the user, want my dotfiles to exist per-app in $HOME, the way they have since I started using UNIX in the 1980s, I have no recourse. Not being able to configure the location of config files to the place they already were in the name of "user choice" is incoherent at best.

A fellow commenter pointed out that it makes excluding cache files from backups much easier. That is a great technical justification, which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.

I further reject the notion that this is something being "done to the user" by the software. Software is a tool of the user, refusing to learn how the tool works and pretending that the program you chose to execute is some kind of rude houseguest is just wheelspinning.

> which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.

That's configurable! Check out :h directory , or just add *.sw? as a filter in .gitignore.

Configurable is best. XDG peeps get what they want, the rest of us get what we want.

I know it's configurable; that's why I included the phrase "by default." The linked issue does not address this.

And I'm not sure, maybe you just didn't read the rest of my comment, but in it I explain that when XDG people get what they want, it becomes literally impossible to configure the software to revert to the previous norm. In other words, when XDG people get what they want, nobody else can.

I'm not sure I'm following you. What state are we considering to be "what XDG wants"? If it's just adding XDG as an option for where config is, then that's fine. If it's replacing custom config location with XDG only, then I would certainly agree that they are unduly influencing things.

It depends on how XDG dirs are handled by the software. If we're forced to use the env vars then it's not really optional anymore. But if the program can default to another location without those env vars set (trivial with an ldpreload script or something), then it supports both.

Vim can be configured to use XDG dirs, if you really want to. Does Neovim limit users to only XDG for its config? I can't think of many pieces of software that outright force XDG. Maybe GNOME stuff?

Every software that follows XDG-basedir stores config in ~/.config if the env var isn't set.

Imagine you have program "foo" which has config, cache, and so on. What XDG-basedir env vars can you set to make it use ~/.foo for all of that? If you try, then because software following XDG-basedir probably doesn't anticipate that XDG_CONFIG_HOME and XDG_CACHE_HOME might have the same value (and because your time is more valuable than auditing the code to find out whether they did anticipate this), you are left with .foo/config, .foo/cache, and .foo/local.

You have created a new "home", and, more importantly, you disallow "foo" from ever spawning a separate program that also uses the same XDG vars. Spawning programs is rather a central Unix principle if you have many tools that each do one thing well.