Re: xdg-directories.el

["francisco.colaco@gmail.com" <francisco.colaco@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5113 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6081 bytes --]