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 <eliz@gnu.org>:
> From: "francisco.colaco@gmail.com" <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.