Default to ~/.config/gmailctl for newly created config dirs

[lgarron]

This is a minimal fix for #144

[mbrt]

Thanks for the contributions!

There are also a bunch of references to the old directory in the main README.md. Could you update them?

I think the new behavior should also be explained in the gmailctl init --help message. Something along the lines that the default config directory location moved from one location to the other.

Sorry for the back and forth, I missed these points in the earlier review. Thanks!

[mbrt]

I thought about this a bit more and the problem with this PR is that it doesn't solve the problem for all platforms. I think the original issue is more about OSX and Windows, where polluting the home directory with dotfiles is not common.

I'm afraid this just introduces one more variant without really tackling the underlying issue.

[lgarron]

I thought about this a bit more and the problem with this PR is that it doesn't solve the problem for all platforms. I think the original issue is more about OSX and Windows, where polluting the home directory with dotfiles is not common.

I'm afraid this just introduces one more variant without really tackling the underlying issue.

I mean, that's fine if you'd prefer to match OS conventions more closely. How would you feel about using https://github.com/adrg/xdg to compute the config path?

[mbrt]

Using adrg/xdg seems better to me. We would make the behavior more complicated, but at the same time behave in a more standard way. I also took a look at the library and it seems well maintained and low dependency.

This should be explained decently in the docs, but I would agree with that change.

[github-actions]

This pull request is stale because it has been open for 30 days without activity.
This will be closed in 7 days, unless you add the 'lifecycle/keep-alive' label or comment.

[lgarron]

Using adrg/xdg seems better to me. We would make the behavior more complicated, but at the same time behave in a more standard way. I also took a look at the library and it seems well maintained and low dependency.

This should be explained decently in the docs, but I would agree with that change.

It's been two years, but I finally got around to this: #455

(I've been using a local build with this PR in the meanwhile.)