I'm vaguely -1 on this. There are numerous locations shared with other very common tooling and projects and we're now introducing a new directory. That feels like more clutter, not less

I'm vaguely -1 on this. There are numerous locations shared with other very common tooling and projects and we're now introducing a new directory. That feels like more clutter, not less

I do not see how this would ever produce more clutter, even if you have a single tool that uses .config it would mean that you would replace one file with one folder in project root, keeping the same number of entries. With two tools, you can already start seeing the benefits. Also keep in mind that this is not about forcing anyone to use the new locations, is only allowing them to use it if they want. Yes, I do expect that to take time, even adoption of XDG_HOME_CONFIG took an insane number of years. Still based on the fast that it was a relative success, I think that one should work fast.

To give some extra feedback on why I proposed this, please take a look at https://dot-config.github.io/ - I am trying to seek adoption of .config for repository level configs, similar to user level config in order to allow us to declutter project configurations. That movement is in early stage but if you check dot-config/dot-config.github.io#2 you will also see that it is not something new, over the years many others raised the same questions. The tricky bit is to get the first 10 early adopters.

Sorry, I should elaborate "vaguely" was intended to be a "weak" or "non-blocking". I don't hate it, but I'm not convinced of the value.

I also wonder if the right way of handling this is to search for a config file with that path, or if we should allow someone to specify a config-dir that tells us where to look for that information.