Eli, I have not created a perfect package, I have just shared something I personally use, and that works for my purposes (to separate files I want to backup from those I do not want; and configuration files which I share among machines from data files which are generated in the machine, like recentf or Emacs session files). I emphasize the idea that Emacs must adhere to the XDG protocol, as almost all other applications are. Emacs does so much more now than twenty-five years ago, when I started using it, and the configuration files have also grown concomitantly. About the adoption, I think it is a non-issue. At the very least, user-emacs-directory should be changed to ~/.local/share/emacs, if it exists, and keep on being ~/.emacs.d if not. As far as I know, no package has "~/.emacs.d" hardwritten, so the transition should be painless. In the same spirit, user-emacs-init should look first for (locate-user-config-file "init.el") then ~/.emacs.d/init.el and then the usual choices, as detailed in the Emacs manual. (At this moment, ~/.emacs takes precedence over ~/.emacs.d/init.el, which is annoying. Debian and Fedora tend to install a .emacs of their own, and a pretty useless one. I have been fooled once, surprised my configuration in ~/.emacs.d/init.el was not called.) About some of the useful suggestions you made: - s-chomp does replace a longer elisp call chain. That is why a few months ago I made the choice to use s, which I can tell is a good library. I have never made the change to f, though, not because the lack of want, but because expand-file-name worked well enough. - I am aware that xdg-user-dir reads the environment variables, which actually are in the standard. I guessed, maybe wrongly, at the time, that xdg-user-dir would be the future-proof standard way of getting the values. Thinking better, I will change that. - About the API: I am open to all suggestions. Change at will, and if you want, I will provide you with full access to the Github repository! - About the doc strings: I have to revise those once again. Thanks for your input. I will try do address most of the changes today. Francisco Colaço 2016-09-07 15:18 GMT+01:00 Eli Zaretskii : > > From: "francisco.colaco@gmail.com" > > Date: Tue, 6 Sep 2016 16:24:56 +0100 > > > > I would request that this package (after revision and a possible API > change) becomes part of GNU Emacs. I would also suggest that > ~/.config/emacs/init.el (the result of "(locate-user-emacs-config-file > "init.el") becomes in vanilla emacs part of the chain to determine > user-init-file. > > Thanks. Some comments below. > > . IMO, we need to figure out where this stuff fits into Emacs. Do > the XDG places override the traditional Emacs places, or the other > way around? Do we even want this, and if so, why? > > . If the XDG places override the traditional ones, an important > aspect to consider is the transition period: the first Emacs > version that turns on this feature will need to help users migrate > from the old places to the new ones. This requires support code > that I don't see in your package. > > . The package in its present form "needs work" before it can be > admitted into Emacs: > > . The few settings that must be preloaded and the minimal support > code should go to files.el; the rest of the package doesn't have > to be preloaded, AFAICT. > > . The package currently depends on s.el for a single function; I > think that dependency should be removed, and standard facilities > used instead. > > . The usage of shell commands, such as xdg-user-dir, is > problematic, at least on non-Posix platforms. I wonder if that > script is really needed, or how important it is for the overall > functionality. AFAICS, the script just accesses some environment > variables and reads a file, something we could do from Lisp. > > . Symbols (functions, variables) defined by the package should have > a unique package-specific prefix, in this case probably "xdg-". > > . Maybe it's just me, but I find some of the terminology, and the > respective variable/function names, confusing, because they clash > with the long tradition of the Emacs terminology. For example, > "user file" has a precise meaning in Emacs, so the purpose of > xdg-get-user-file is a surprise. Likewise with "emacs data > file". More generally, the naming convention doesn't sound > consistent: some functions that return file names are called > locate-SOME-file, but other similar functions are > xdg-get-SOME-file. > > . The doc strings need various minor fixes, as they include typos > and copy/paste errors. > > . A minor nit: GNU coding standards frown on using "path" to refer > to anything but PATH-style directory lists; use "file name" or > "directory name" instead. > > Thanks for working on this. >