skeeto / elfeed

An Emacs web feeds client
The Unlicense
1.49k stars 116 forks source link

XDG_CONFIG_HOME #303

Open leliamesteban opened 5 years ago

leliamesteban commented 5 years ago

As far as I can tell, elfeed doesn't support XDG_CONFIG_DIR. Is this something you would consider implementing?

Thank you

leliamesteban commented 5 years ago

For reference, here is the git implementation and the karabiner-elements implementation

skeeto commented 5 years ago

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.

skangas commented 5 years ago

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.

skeeto commented 5 years ago

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:

1) 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.

2) 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.

skangas commented 5 years ago

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.

skangas commented 5 years ago

FWIW, I'm not a champion of this change. Just pointing out that it could be done using this function.

jimporter commented 3 years ago

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. :)

PRESFIL commented 1 year ago

Any updates on this?

Thaodan commented 1 year ago

Have you tried the no-littering package? It does something very similar.