FYI: I wrote xdg basedir package for Go.
https://github.com/zchee/go-xdgbasedir

I want to take a stab on this.

@xiaq are you OK with the following design?

• ~/.elvish/ exists: Do not change behavior because this is most likely a legacy (pre-xdg) install. Output a message on launch to advertise moving to $E:XDG_CONFIG_HOME/elvish.
• Add a flag -config that defaults to $E:XDG_CONFIG_HOME/elvish or ~/.config/elvish.
  dataDir from

  elvish/runtime/runtime.go

  Line 53 in 702edb3

  var dataDir string

  gets assigned that flag value.

I would use @zchee's implementation with the Native mode to honor Apple's guidelines, see https://github.com/zchee/go-xdgbasedir/blob/7a0b8922e178cedb342090b90ef662084d88eba8/xdgbasedir.go#L16-L27

I'm OK with following XDG. However if we are going to move directory, better make it the last directory move we ever have to do. The current .elvish directory has 3 things:

• .elvish/rc.elv: This is configuration.
• .elvish/db: This is user's data.
• .elvish/lib: This is libraries.

XDG has a clear distinction between configuration and data, so clearly rc.elv and db should be in different places. I don't know which bucket .elvish/lib falls into though, the specification does not say. It's worthwhile researching what other languages that respect XDG do.

I'd also prefer that we have a separate implementation in Elvish instead of depending on go-xdgbasedir. I don't mean to discredit their effort, but the main reason is that this behavior needs to be documented in Elvish's documentation, and it's easier to make sure that the behavior and documentation are in sync when they are part of the same codebase.

Elvish also creates temporary files for the socket used for communication with the storage daemon; this is now always /tmp/elvish-$uid. We can use XDG's runtime directory for this, but this can be done separately.

To summarize there are several more things to do:

1. Researching where to put .elvish/lib.
2. Writing Elvish's own implementation for finding the directories.
3. Documenting the behavior in Elvish's documentation.
4. [Optional] Follow XDG for the runtime directory too.

maybe the lib should be sourced from multiple places, to also account for potential elvish code managed by system package manager and maybe to separate epm fetched libs and user's. something like /usr/share/elvish/ -> $XDG_DATA_HOME/elvish/lib -> $XDG_CONFIG_HOME/elvish/lib. maybe thats overkill.

@SolitudeSF Yes, I think this is a good opportunity to introduce a system-wide lib too.

On a related note, after reading the XDG spec, it seems that the particular definition it uses for "data files" is not so much as "user's activity data", but more like "assets used in programs", as it cites /usr/share as one of the default paths for data.

In this light, it seems that @fehnomenal's original idea of treating everything as config would make a lot of sense. And since we are back to dealing with just one directory, it makes more sense to implement it ourselves now.

A system-wide lib would be really cool. In preparation to it I will implement the complete XDG Basedir spec. The lib could then be placed somewhere in $XDG_DATA_DIRS.

For the current task I will place

• rc and libs into $XDG_CONFIG_HOME/elvish
• db into $XDG_CACHE_HOME/elvish (it only contains "temporary" data right? I.e. is not configuration)
• the socket into $XDG_RUNTIME_DIR/elvish.sock
• daemon logs into $XDG_DATA_HOME/elvish (debatable but is there a better place?)

The specification defines cache as "non-essential data", which is pretty vague. But a useful litmus test would be "if cache files are removed, the behavior of the program does not change, except maybe the next startup is slower". This is not true for db.

The XDG base directory specification is written in too vague a way, and it is impossible to make good choices. Treating the entire .elvish directory as config might as well be the least bad one.

Hmm, after looking at how Fish stores its history in ~/.local/share/fish, I am leaning a bit towards treating db as a data file now.

The way I think about it is whether the information is unique to a system, in which case it belongs in ~/.local/share/appname, or is part of the apps configuration, in which case it belongs in ~/.config/appname. In other words, is it something I probably want to sync to every system on which I run the app (such as when setting up a new system)? If yes, ~/.config, else ~/.local/share.

Call me old-fashioned, but I find XDG confusing and cumbersome, I much prefer plain dot-dirs under $HOME. But I won't object to the change, as I see a lot of other tools following XDG 😐. Also, it's great if a system-wide config dir comes from this 😄

Right. I am less sure whether the complexity is worthwhile too, especially as the spec doesn't really have good definitions of how to use the different kinds of directories.

The spec is also more complex than I had, and likely most people had, expected. It's a good idea to adopt some standard, but that doesn't equate to adopting any standard. In this particular case, I am no longer sure whether the XDG base directory spec is the correct standard to adopt.

People expect that XDG is supported. Storing everything in $HOME is incorrect approach.

If one wants to see how the XDG spec can be adapted to different situations, the arch wiki page is quite good: https://wiki.archlinux.org/index.php/XDG_Base_Directory