Let's put transient caches/state/files/crap in .emacs.d/.cache

[Fuco1]

I've been cleaning up my config and doing some gitignore grooming and I came to the realization I had over 100 ignore rules in there :O.

Packages should put their caches and files holding state in some "centralized" directory. I propose (locate-user-emacs-file ".cache"). This is an analogy of $XDG_CACHE_HOME which points to $HOME/.cache by default (base dir spec).

It should really be enforced by emacs proper, but for now we can at least do it this way. Ideas?

---

This is what I end up with. Note that some directories have multiple files under them. (oh, and I autosave scratch buffers there too, I lost my data too many times now :))

[dieggsy]

Yeah, my emacs.d is getting pretty messy and I really like this idea. How are you implementing this?

[Fuco1]

I did this by customizing every package separately, but the ideal state would be to "enforce" this as a rule upstream, so that package authors default to correct place automatically.

[xuchunyang]

I use https://github.com/tarsius/no-littering, it's available on Melpa.

[dieggsy]

@xuchunyang thanks! that looks like a great solution.

[Fuco1]

It's good, but depends on other people submitting patches for third-party packages. Unless it gets really big it won't grab that much attention.

[dieggsy]

@Fuco1 I think that in the end, as you say, enforcing this as a package development standard is the correct way to go about this, but until then, no-littering can provide an alternative. There's so many emacs packages that depending on PR's is probably the only sane way to do it for now, and this shouldn't be an issue - if it's a good package, we should use and promote it as well as promote contribution.

[alphapapa]

I think it would be better to use ~/.cache/emacs.d, because it's a standard place for cache files and anything that shouldn't be considered permanent. Especially, it's a standard place to exclude from backups. In contrast, ~/.emacs.d/cache won't automatically be excluded from users' backups, so it won't have the benefit of not cluttering up backups with temporary data.