XDG base directory spec compliance

[elizagamedev]

mujmap is based on lieer Lieer in terms of configuration layout, and has the following requirements:

• The config file (mujmap.toml) is in a directory which is at the root of or a subdirectory of a notmuch-managed mail directory.
• The state file (mujmap.state.json) and lock file (mujmap.lock) generated by mujmap are placed in this same directory.

According to the XDG base directory spec, the correct locations for these files are:

mujmap.toml : $XDG_CONFIG_HOME/mujmap/

mujmap.state.json : $XDG_DATA_HOME/mujmap/

mujmap.lock : $XDG_RUNTIME_DIR/mujmap/

However, I’m not sold on the usefulness of changing mujmap to comply with this spec, as the following problems arise:

• Filesystems shared between two operating systems on the same device would have to maintain independent configurations of the same maildir. You could argue that given mujmap’s purpose, you could just synchronize instead, but if you have gigabytes and gigabytes of mail then this could be wasteful.

• Similar to above, the current system “just works” on networked filesystems.

• This might be a matter of opinion, but the configuration process might become more confusing. mujmap would need to support multiple maildir configurations in the same config file, and these configuration options would need to point to specific mail directories. The -C option would need to be replaced with something like --name.

  Perhaps I specifically am biased to think that the way lieer does it is easier because I am used to using it already for my work email. But I do think there is something somewhat intuitive to the concept of “this mail directory contains the mujmap config/state, therefore the mail files here are owned by mujmap”, and it also communicates to the user “you can have separate mujmap setups, and they are all independent by design” in a clear way.

This issue exists both as a space for me to explain why mujmap is the way it is and also a place for people to try and convince me that I’m wrong.

[elizagamedev]

@robn for your consideration :)

[robn]

I have thought a lot about this over the last few days, and I will do my best to keep this succinct.

The specific thing I actually want: totally distinct and isolated notmuch+mujmap+neomutt setups for home and for work. This is possible right now through creative use of notmuch environment variables, but its fragile and kind of a pain too. XDG dirs are only incidental to that.

I don't personally think XDG dirs are particularly compelling in general, because my preference is to group related things together in a single dir so I don't get lost. But, they're the way that notmuch has chosen to provide a convenient split config method via NOTMUCH_PROFILE, and once you've done one thing an annoying way, its often easier to do the next thing that way too. So what I want, I think, is the ability to be explicit about where all the moving parts live, even if that's not the default.

I believe we can cover both your and my wants comfortably as follows:

1. Introduce separate mujmap config items maildir_path and state_path, which point to the location of the maildir (parent of the cur/new/tmp dirs) and the state dir (parent of the mujmap.state.json and mujmap.lock files). Initially, we default these as we currently do. The path search prefix is set as the difference between the notmuch mail_root and the maildir_path, just as it is now.

2. Change the behaviour of the -C switch. If it points to a directory, it does what it does now - find mujmap.toml there and default maildir_path and state_path to it. If its a config file, load it in. If not set, take maildir_path from notmuch mail_root, and make an appropriate state_path default (uncertain, but maybe its XDG_STATE_HOME, or maybe just $HOME/.mujmap).

3. As a stretch goal, --profile=<name>. This is the full-XDG mode, that sets config, maildir and state dirs in a XDG-sensible way, that also initialises notmuch with the profile name, so everything looks and feels the same.

Notes:

• I think really all any of this is the ability to set the paths separately, and then various "modes" that just describe how to set the defaults if the paths are not explictly set. Maybe I would call them ConfigMode::Directory, ConfigMode::File and ConfigMode::Profile.

• The "path prefix" config option I suggested in #27 is not necessary here. In all cases, its just a comparison between the notmuch mail_root and the mujmap maildir_path and computing an appropriate prefix, if any. If they're the same, there's nothing to do, and if its a totally weird situation then we can crash out. If that ends up being a common enough weird situation, then we can do something there, maybe add a new mode.

I will have a crack at this and see what comes out. There'll be some daft surprise I'm sure, but its still sitting well we with me after a few days chewing on it so I reckon its somewhere close. Hopefully I am not a total fool!