Experimental XDG support

[rossabaker]

Inspired by #171, I tried adding a third variable for the cache. To minimize breakage, I did not change the default directories, but an XDG config could look something like this:

  (use-package no-littering
    :init
    (setopt no-littering-config-directory (expand-file-name "emacs/" (xdg-config-home)))
    (setopt no-littering-state-directory (expand-file-name "emacs/" (xdg-state-home)))
    (setopt no-littering-cache-directory (expand-file-name "emacs/" (xdg-cache-home)))

If others like the approach, I'd be happy to polish it up into a proper pull request. If not, I'll rename my repo to avoid confusion. Either way, thanks for the wonderful project!

[thkoch2001]

I like this first step towards the XDG standard, but please don't stop half-way.

https://specifications.freedesktop.org/basedir-spec/latest/

There are 5 directories: cache, config, data, runtime, state

This table (from Debian Wiki) might help to decide what to put where:

	DATA	CONFIG	STATE	CACHE	RUNTIME
sync across machines?	yes?	yes	no	no	no
manage in VCS (Git)?	no	yes	no	no	no
should be backed up?	yes	yes	yes	no	no
can live in tmpfs?	no	no	no	yes	yes?
contains much data?	yes	no	no	yes	no

Some history: https://blog.koch.ro/posts/2024-01-02-good-things-state-folder.html

[rossabaker]

I agree, and have added data and runtime, without yet assigning anything to them. I suspect they're much less common in this domain than the other three. I'm only familiar with a fraction of the packages no-littering covers, but:

• Any variable with temp or lock in the name is a likely candidate for runtime.
• Emacs packages themselves are probably data, but that may be outside the scope of no-littering.

A more thoughtful pass through the whole list is still needed.

[tarsius]

I'm not opposed to the idea, but I am also not exited about taking on more work.

Even without moving it in a direction I had not in mind originally, maintaining this package has unfortunately turned out to be more work than I had anticipated. I would be interested in finding a co-maintainer, or contributors who are interested in helping out beyond just theming a few additional packages they use.

I think in the short- to midterm, it would be best if you maintained this as a friendly fork. (Which doesn't mean that I would not be willing to provide some feedback and/or that I do not have any ideas of my own in this direction. But I would like someone else to do the experimenting, dealing with unexpected complications, and making sure all the existing themings are properly updated.)