Eli, I have seen once again the source code for xdg-user-dir, and there is no environment variables until one runs ~/.config/user-dirs.dirs (or the file in $XDG_CONFIG_HOME). That is how, _in the script_, the environment variables for user directories are set. They aren't normally set, only get set for specific packages. We would either have to read the lines of user-dirs.dirs and get the values after the = sign and inside the quotes; or execute the file through a shell, as intended, and read the directory names from the environment values. I would not bet on a simple file readout, for one day someone will end up replacing a directory name by a backticked shell script. Now, I remember why I have used xdg-user-dirs in the first place for the user directories: not using it would be reimplementing it in Emacs Lisp, a needless effort. If xdg-user-dirs does not exist then there is no point in having a PICTURES or DOCUMENTS user directory. In MS Windows the directories are determined in a totally different method. In OSX almost all goes to ~/Library, according to an answer to http://stackoverflow.com/questions/3373948/equivalents-of-xdg-config-home-and-xdg-data-home-on-mac-os-x So, to perfect the package in order to have a solid candidate, can you suggest new function names? Francisco Colaço 2016-09-07 15:59 GMT+01:00 francisco.colaco@gmail.com < francisco.colaco@gmail.com>: > 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. >> > >