From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "francisco.colaco@gmail.com" Newsgroups: gmane.emacs.devel Subject: Re: xdg-directories.el Date: Wed, 7 Sep 2016 16:31:18 +0100 Message-ID: References: <83shtbaj4b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e014934accd5701053bec9a6f X-Trace: blaine.gmane.org 1473262310 20281 195.159.176.226 (7 Sep 2016 15:31:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 15:31:50 +0000 (UTC) Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 17:31:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhepA-0004GU-JL for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 17:31:40 +0200 Original-Received: from localhost ([::1]:41576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhep8-0000GX-EM for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 11:31:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bheox-0000Ef-QI for emacs-devel@gnu.org; Wed, 07 Sep 2016 11:31:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bheou-0005ki-J6 for emacs-devel@gnu.org; Wed, 07 Sep 2016 11:31:26 -0400 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:36675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bheoq-0005jV-Eb; Wed, 07 Sep 2016 11:31:20 -0400 Original-Received: by mail-wm0-x22b.google.com with SMTP id b187so122320402wme.1; Wed, 07 Sep 2016 08:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RgDxFrA0TnCAclKaAnDIbk+UpOn90m5G8EmjcfThbE4=; b=o0XZSK2OduwFxnUmf/N7p7/at8D6A9bDIO0YZtbV/0fdfTzw9mvTr0Ip/oJyKPYN5C dtj3jIBrdJpt4pLSYIs6YWCKnduQPkcqQQruq5cQsy4dYYUNyHdx+8OqC125GBCZl589 6OxlRE126JiHNdYI8EmiuPFqpRaiWyFzx1t5QNikvbbnV7Ychn1eQ8W9ZnnmJlHFhkbL 4AHV7irNQYmID8JXx2dELJWID+Gy3piKIjie+ivZF6jMsJysnKEwTxzA+XdBf0k+yOp2 ndd4ygLlj22CkzlMyqeBXNIgjjqbz743yHt8sTFxo9ZnFr5pDDylE9shkqxIHLfsNx56 o1xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RgDxFrA0TnCAclKaAnDIbk+UpOn90m5G8EmjcfThbE4=; b=eXzaj4WB2ioKzSAX3LGYD1txtFsNRBwLR99D8O4wqpLeUYYLnK+PNqlLWMvvfEbq4I v2O/EKw3Zrkp5XisOcQw/BJASaDDUcZa8XJnl9LNKcy5s9rdSH6a0p6cPuiSRn5Jfu7Q vCBGALmpt5dI2pZ6iAXXI510UshXvE7LcOINJEy7RyjNJl5EhDB2u6TQKdOlMfAO7oy4 OwoHXi7WrZhwhqUvM1ZD6mDKSiQM+ONu3Iu5ziI/03lj2OhNO8CHWewNq84/1G8Z9Y9q J3BWwLbV8aOVnZERKH50mxn/YXybLAG9fjEerWy2/ks7IGtyWPo/H3c8PZhMDVyq7nuO Jzpw== X-Gm-Message-State: AE9vXwNqfZy6jxLlJif4KXzs3oqNTAc23gKzLWgXRPl6rv2UVkBpFatm/j2KDzaRnza1JB2xFQ6lXjgRyq5HpQ== X-Received: by 10.194.238.170 with SMTP id vl10mr47966035wjc.18.1473262279020; Wed, 07 Sep 2016 08:31:19 -0700 (PDT) Original-Received: by 10.28.30.140 with HTTP; Wed, 7 Sep 2016 08:31:18 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207246 Archived-At: --089e014934accd5701053bec9a6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D 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-a= nd-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=C3=A7o 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 packag= e > has "~/.emacs.d" hardwritten, so the transition should be painless. In t= he > same spirit, user-emacs-init should look first for (locate-user-config-fi= le > "init.el") then ~/.emacs.d/init.el and then the usual choices, as detaile= d > 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, an= d > a pretty useless one. I have been fooled once, surprised my configuratio= n > 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, tha= t > 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 yo= u > 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=C3=A7o > > > 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. >> > > --089e014934accd5701053bec9a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0 Eli,

I have seen once a= gain the source code for xdg-user-dir, and there is no environment variable= s until one runs ~/.config/user-dirs.dirs (or the file in $XDG_CONFIG_HOME)= .=C2=A0 That is how, _in the script_, the environment variables for user di= rectories are set.=C2=A0 They aren't normally set, only get set for spe= cific packages.

We would either have to read the lines of use= r-dirs.dirs and get the=20 values after the =3D sign and inside the quotes; or execute the file throug= h a shell, as intended, and read the directory names from the environment v= alues.=C2=A0 I would not bet on a simple file readout, for one day=20 someone will end up replacing a directory name by a backticked shell=20 script.

Now, I remember why I have used xdg-user-dirs in the first p= lace for the user directories: not using it would be reimplementing it in E= macs Lisp, a needless effort.

If xdg-user-dirs does not exist then = there is no point in having a PICTURES or DOCUMENTS user directory.=C2=A0 I= n MS Windows the directories are determined in a totally different method.= =C2=A0 In OSX almost all goes to ~/Library, according to an answer to http://stackoverflow.com/questions/3373= 948/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?

=C2=A0=C2=A0 Francisc= o Cola=C3=A7o


=
2016-09-07 15:59 GMT+01:00 francisco.colaco@gmail.com &= lt;francisc= o.colaco@gmail.com>:
Eli,

I have not = created a perfect package, I have just shared something I personally use, a= nd that works for my purposes (to separate files I want to backup from thos= e 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 sessio= n files).=C2=A0 I emphasize the idea that Emacs must adhere to the XDG prot= ocol, as almost all other applications are.=C2=A0 Emacs does so much more n= ow than twenty-five years ago, when I started using it, and the configurati= on files have also grown concomitantly.

About the adoption, I = think it is a non-issue.=C2=A0 At the very least, user-emacs-directory shou= ld be changed to ~/.local/share/emacs, if it exists, and keep on being ~/.e= macs.d if not.=C2=A0 As far as I know, no package has "~/.emacs.d"= ; hardwritten, so the transition should be painless.=C2=A0 In the same spir= it, user-emacs-init should look first for (locate-user-config-file "in= it.el") then ~/.emacs.d/init.el and then the usual choices, as detaile= d in the Emacs manual.

(At this moment, ~/.emacs takes precede= nce over ~/.emacs.d/init.el, which is annoying.=C2=A0 Debian and Fedora ten= d to install a .emacs of their own, and a pretty useless one.=C2=A0 I have = been fooled once, surprised my configuration in ~/.emacs.d/init.el was not = called.)

About some of the useful suggestions you made:

-=C2=A0 s-chomp does replace a longer elisp call cha= in.=C2=A0 That is why a few months ago I made the choice to use s, which I = can tell is a good library.=C2=A0 I have never made the change to f, though= , not because the lack of want, but because expand-file-name worked well en= ough.

- I am aware that xdg-user-dir reads the environment var= iables, which actually are in the standard.=C2=A0 I guessed, maybe wrongly,= at the time, that xdg-user-dir would be the future-proof standard way of g= etting the values.=C2=A0 Thinking better, I will change that.

= - About the API: I am open to all suggestions.=C2=A0 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.
<= div>

Thanks for your input.=C2=A0 I will try do add= ress most of the changes today.

=C2=A0 Francisco Cola=C3= =A7o


2016-= 09-07 15:18 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> From: "francisco.colaco@gmail.com" <francisco.colaco@g= mail.com>
> Date: Tue, 6 Sep 2016 16:24:56 +0100
>
> I would request that this package (after revision and a possible API c= hange) becomes part of GNU Emacs.=C2=A0 I would also suggest that ~/.config= /emacs/init.el (the result of "(locate-user-emacs-config-file &qu= ot;init.el") becomes in vanilla emacs part of the chain to determine u= ser-init-file.

Thanks.=C2=A0 Some comments below.

=C2=A0. IMO, we need to figure out where this stuff fits into Emacs.=C2=A0 = Do
=C2=A0 =C2=A0the XDG places override the traditional Emacs places, or the o= ther
=C2=A0 =C2=A0way around?=C2=A0 Do we even want this, and if so, why?

=C2=A0. If the XDG places override the traditional ones, an important
=C2=A0 =C2=A0aspect to consider is the transition period: the first Emacs =C2=A0 =C2=A0version that turns on this feature will need to help users mig= rate
=C2=A0 =C2=A0from the old places to the new ones.=C2=A0 This requires suppo= rt code
=C2=A0 =C2=A0that I don't see in your package.

=C2=A0. The package in its present form "needs work" before it ca= n be
=C2=A0 =C2=A0admitted into Emacs:

=C2=A0 =C2=A0. The few settings that must be preloaded and the minimal supp= ort
=C2=A0 =C2=A0 =C2=A0code should go to files.el; the rest of the package doe= sn't have
=C2=A0 =C2=A0 =C2=A0to be preloaded, AFAICT.

=C2=A0 =C2=A0. The package currently depends on s.el for a single function;= I
=C2=A0 =C2=A0 =C2=A0think that dependency should be removed, and standard f= acilities
=C2=A0 =C2=A0 =C2=A0used instead.

=C2=A0 =C2=A0. The usage of shell commands, such as xdg-user-dir, is
=C2=A0 =C2=A0 =C2=A0problematic, at least on non-Posix platforms.=C2=A0 I w= onder if that
=C2=A0 =C2=A0 =C2=A0script is really needed, or how important it is for the= overall
=C2=A0 =C2=A0 =C2=A0functionality.=C2=A0 AFAICS, the script just accesses s= ome environment
=C2=A0 =C2=A0 =C2=A0variables and reads a file, something we could do from = Lisp.

=C2=A0 =C2=A0. Symbols (functions, variables) defined by the package should= have
=C2=A0 =C2=A0 =C2=A0a unique package-specific prefix, in this case probably= "xdg-".

=C2=A0 =C2=A0. Maybe it's just me, but I find some of the terminology, = and the
=C2=A0 =C2=A0 =C2=A0respective variable/function names, confusing, because = they clash
=C2=A0 =C2=A0 =C2=A0with the long tradition of the Emacs terminology.=C2=A0= For example,
=C2=A0 =C2=A0 =C2=A0"user file" has a precise meaning in Emacs, s= o the purpose of
=C2=A0 =C2=A0 =C2=A0xdg-get-user-file is a surprise.=C2=A0 Likewise with &q= uot;emacs data
=C2=A0 =C2=A0 =C2=A0file".=C2=A0 More generally, the naming convention= doesn't sound
=C2=A0 =C2=A0 =C2=A0consistent: some functions that return file names are c= alled
=C2=A0 =C2=A0 =C2=A0locate-SOME-file, but other similar functions are
=C2=A0 =C2=A0 =C2=A0xdg-get-SOME-file.

=C2=A0 =C2=A0. The doc strings need various minor fixes, as they include ty= pos
=C2=A0 =C2=A0 =C2=A0and copy/paste errors.

=C2=A0 =C2=A0. A minor nit: GNU coding standards frown on using "path&= quot; to refer
=C2=A0 =C2=A0 =C2=A0to anything but PATH-style directory lists; use "f= ile name" or
=C2=A0 =C2=A0 =C2=A0"directory name" instead.

Thanks for working on this.


--089e014934accd5701053bec9a6f--