Re: xdg-directories.el

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

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

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

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