> To argue that non-desktop software should apply a desktop specification that they weren't involved in developing seems rather insane, especially since they are and have been following the established convention.
So what, stuff changes over time - and it's not that hard to migrate, either warn the user, or do the migration at first start. Good software should move with the times, not be perpetually frozen.
How many documents tell you to configure ssh with something in ~/.ssh/config and if the change is made, will now need to be changed to say put your config in one of many paths depending on the version you use?
What if you migrate your config and then roll back to an earlier version?
What if you use your home directory on multiple systems, some which have varying versions of the tool, loading the config from various places (network mounted home directories are a practice in some companies)?
What if you don't upgrade for ten years, and the migration code is gone by then?
What if you operate on a mix of systems of various ages, some which have the new path and some which have the old?
What if the migration code has a security vulnerability?
Personally, I don't see where the benefit is that pays for anywhere near any of this cost. Maybe if you're a desktop app that is within the scope of standards put out by the XDG, you might want to consider accepting this standard of theirs too; and sure, if you're a new application, seems like a might as well?
I thought about this, too. One fix would be for ssh to make a solid process that walks you through setting up your ssh config. Then it could be placed anywhere you like, and the preference would be set. Those docs would just reference the setup switch or tool, instead.
If you force me to migrate, I'm probably ditching your software. The inability to keep a stable user contract is a deep flaw that impacts too much software these days.
Everyone should do what emacs does (and a lot of software does): first look for .emacs for a config … not there? Check .emacs.d … still not there? .config/emacs …
That's not exactly what emacs does: if ~/.config/emacs isn't there, then it will default to creating ~/.emacs.d/ and ~/.emacs, even if the XDG env vars are set. Basically, emacs supports XDG config if you really want it to, but it's not the default way of using emacs. And of course, it only uses ~/.config/emacs, none of the other XDG folders. If you download a package from MELPA, that's still going to .config/emacs, as far as I know.
But also not without the downsides, because what do you do if multiple files are found? And how will you communicate that to the user, if at all? Lots of room for confusion here: "why aren't my changed taking effect?!", "where is this setting coming from, it's not in my file?!" and things like that.
Things like bashrc and vimrc have been "standard" for decades; that's not a "non-standard configuration", it's what everyone uses today. And Neovim only supports ~/.config/nvim/init.vim judging from the manpage(?) If it doesn't then this only underscores my point that all of this is apt to lead to confusion.
Either way, it had a clean break from Vim and didn't have to deal with people who have been using Neovim for decades (lots of things are different compared to Vim and it's not intended to be compatible in the first place).
So what, stuff changes over time - and it's not that hard to migrate, either warn the user, or do the migration at first start. Good software should move with the times, not be perpetually frozen.