elfeed
elfeed copied to clipboard
XDG_CONFIG_HOME
As far as I can tell, elfeed doesn't support XDG_CONFIG_DIR. Is this something you would consider implementing?
Thank you
For reference, here is the git implementation and the karabiner-elements implementation
So I thought about this and I'm not yet convinced that it's appropriate. However, I did still capture the change (448ad647) that would be necessary on my xfg-config-home branch. My reasons against it are:
Elfeed lives within the Emacs ecosystem, not on its own. In Emacs, the convention is for this sort of thing to be configured using Emacs Lisp rather than the environment. This is indeed the case with the variable elfeed-db-directory, which already allows users to put their database wherever they like.
Elfeed is supported wherever Emacs is supported, which includes platforms where the XDG standard is not appropriate. For example, on Windows it would be more reasonable to use $APPDATA.
The ~/.elfeed directory isn't a configuration directory. Elfeed's configuration lives in the user's Emacs configuration. The ~/.elfeed directory is a database, and so it instead should use $XDG_DATA_HOME. I strongly disagree with the XDG standard using "$HOME/.local/share" as the default location for $XDG_DATA_HOME. That location is for static application data. The standard is dangerously wrong here.
This is further complicated by ~/.elfeed/data acting largely as cache directory since its contents are semi-volatile. So, technically, this part should perhaps be split off and stored under $XDG_CACHE_HOME. However, it's not really obvious how this should work, and it would be incompatible with the current semantics of elfeed-db-directory.
Overall, since it's already under user control there's little benefit to changing Elfeed to follow the XDG Base Directory Specification. If I had thought of it at the very beginning perhaps it would have been fine, but changing an established user interface with little or no practical benefit is annoying to users. It's hard to be sure nothing would break.
How about something like this as the default for elfeed-db-directory
instead?
(locate-user-emacs-file "elfeed" "~/.elfeed")
PS. It does not have to be a configuration file for it to go in ".emacs.d". Emacs already puts bookmarks, auto-save-lists, abbrevs, diary, timelog data, etc., in there. See doc string of user-emacs-directory
.
I'm not going to change the default value at this point since that's a big, breaking change. Anyone who hasn't already manually configured it (probably most users) would need to take action to do so in order to continue operating as before.
I wouldn't choose this particular location anyway since there's no particular convention for it. If I were to default to a place under .emacs.d/ it would be .emacs.d/var/, per this:
https://github.com/emacscollective/no-littering
As your title suggests, there's also a reasonable argument that I should have chosen something compatible with the Freedesktop standards. For the database that would be $XDG_DATA_HOME. There are two problems with this:
-
Elfeed runs on systems where the Freedesktop standard doesn't really apply (i.e. Windows). It should use local conventions, though even that can be troublesome.
-
The default value of XDG_DATA_HOME is dead wrong: ~/.local/share/. The Freedesktop standard messed this one up. That directly is for static program data, analogous to /usr/share. Plus I personally feel that ~/.local/ should be considered somewhat volatile, making it an unsafe place to store user data.
Thank you for the suggestion, though.
I'm not going to change the default value at this point since that's a big, breaking change. Anyone who hasn't already manually configured it (probably most users) would need to take action to do so in order to continue operating as before.
I believe you have misunderstood how locate-user-emacs-file
works. The change I proposed is backwards compatible.
FWIW, I'm not a champion of this change. Just pointing out that it could be done using this function.
I'm not going to change the default value at this point since that's a big, breaking change. Anyone who hasn't already manually configured it (probably most users) would need to take action to do so in order to continue operating as before.
I believe you have misunderstood how
locate-user-emacs-file
works. The change I proposed is backwards compatible.
To elaborate on this, if you have:
~/.elfeed |
~/.emacs.d/elfeed |
Result |
---|---|---|
no | no | ~/.emacs.d/elfeed |
no | yes | ~/.emacs.d/elfeed |
yes | no | ~/.elfeed |
yes | yes | ~/.emacs.d/elfeed |
This ensures that existing users don't have any problems, but new users (or ones who move their DB folder) get the "clutter-free" structure. I think this would be a positive change, since my first reaction upon seeing ~/.elfeed
was to figure out how to change it. :)
Any updates on this?
Have you tried the no-littering package? It does something very similar.