Don't concat directories to file names

Don't concat directories to file names

[Richard Stallman]

    -(defcustom image-dired-dir "~/.emacs.d/image-dired/"
    +(defcustom image-dired-dir (concat user-emacs-directory "image-dired/")

This has the right result, but for clarity such code really ought to
use expand-file-name.

    +@defvar user-emacs-directory
    +This variable holds the name of the @file{.emacs.d} directory.  It is
    +ordinarily @file{~/.emacs.d}, but differs on some platforms.

The text should make it explicit that this is a directory name,
not a file name.

Re: Don't concat directories to file names

[Juanma Barranquero]

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

On 6/13/07, Richard Stallman <rms@gnu.org> wrote:

>     -(defcustom image-dired-dir "~/.emacs.d/image-dired/"
>     +(defcustom image-dired-dir (concat user-emacs-directory "image-dired/")
>
> This has the right result, but for clarity such code really ought to
> use expand-file-name.

I think we should add a function like the one below (with a better
name and docstring, of course), so we can "move" all these
configuration files and directories which are not yet in ~/.emacs.d/,
for example .calc.el, .abbrev_defs, .bdf-cache.el, .emacs-places,
.strokes, .type-break, .timelog, .vip, .viper, .eshell, .quickurls,
.emacs_case_exceptions, .idlwave, .ido-last, .recentf, .emacs_args,
.shadows, .wmncach.el, diary, .eshell/, etc. etc.

The NEW-NAME arg in the function is to allow things like .emacs vs.
init.el, or .completions vs. completions.

WDPT?

             Juanma


Index: lisp/subr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/subr.el,v
retrieving revision 1.555
diff -u -2 -r1.555 subr.el
--- lisp/subr.el	13 Jun 2007 00:03:28 -0000	1.555
+++ lisp/subr.el	14 Jun 2007 14:13:59 -0000
@@ -2051,4 +2051,19 @@
 Note that this should end with a directory separator.")

+(defun user-emacs-file (name &optional new-name)
+  "Convert NAME to an absolute per-user Emacs-specific path.
+If \"~/NAME\" exists, or `user-emacs-directory' does not, return \"~/NAME\".
+Else, return \"`user-emacs-directory'/NEW-NAME\", or /NAME if NEW-NAME is nil."
+  (convert-standard-filename
+   (let ((at-home (expand-file-name name "~")))
+     (cond
+       ;; Backwards compatibility
+       ((file-readable-p at-home) at-home)
+       ;; Preferred for new installations
+       ((file-directory-p user-emacs-directory)
+	(expand-file-name (or new-name name) user-emacs-directory))
+       ;; If ~/.emacs.d/ does not exist
+       (t at-home)))))
+
 \f
 ;;;; Misc. useful functions.

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > I think we should add a function like the one below (with a better
 > name and docstring, of course)

XEmacs has a whole API for finding user data.  The main function is

----------------
`find-user-init-file' is a compiled Lisp function
  -- loaded from "/playpen/src/XEmacs/git-staging/lisp/startup.elc"
(find-user-init-file &optional INIT-DIRECTORY HOME-DIRECTORY)

Documentation:
Determine the user's init file.
----------------

The author is probably Michael Sperber <mike@xemacs.org>.

Re: Don't concat directories to file names

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

>     -(defcustom image-dired-dir "~/.emacs.d/image-dired/"
>     +(defcustom image-dired-dir (concat user-emacs-directory "image-dired/")

rms> This has the right result, but for clarity such code really ought to
rms> use expand-file-name.

Sorry about this.  I will try to fix it up sometime soon.
I believe the reason I chose to use concat rather than
expand-file-name was to be conservative, on the off chance that some
code cared about the precise text in use.

Tom

Re: Don't concat directories to file names

[Tom Tromey]

>>>>> "Juanma" == Juanma Barranquero <lekktu@gmail.com> writes:

Juanma> I think we should add a function like the one below (with a better
Juanma> name and docstring, of course), so we can "move" all these
Juanma> configuration files and directories which are not yet in ~/.emacs.d/

Sounds good to me.

Juanma> +       ;; Preferred for new installations
Juanma> +       ((file-directory-p user-emacs-directory)
Juanma> +	(expand-file-name (or new-name name) user-emacs-directory))
Juanma> +       ;; If ~/.emacs.d/ does not exist
Juanma> +       (t at-home)))))

IMO, if ~/.emacs.d does not exist, and it is what we prefer for the
future, we should create it here.

Tom

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/14/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> XEmacs has a whole API for finding user data.  The main function is
>
> (find-user-init-file &optional INIT-DIRECTORY HOME-DIRECTORY)
>
> Documentation:
> Determine the user's init file.

Could you please elaborate? (Or there is any way to find that
feature's docs, other than installing XEmacs?)

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/14/07, Tom Tromey <tromey@redhat.com> wrote:

> Sounds good to me.

> IMO, if ~/.emacs.d does not exist, and it is what we prefer for the
> future, we should create it here.

I'm not sure. I think the user should be responsible of creating
~/.emacs.d/ if he wants it. Otherwise, if he doesn't want it, the only
way to have the config files in ~/ would be to customize every *-file
or *-directory option...

The setup I propose has the advantage that old setup files are
respected, but if you create ~/.emacs.d/ any new setup file will
automatically go there.

             Juanma

Re: Don't concat directories to file names

[Stefan Monnier]

> I'm not sure.  I think the user should be responsible of creating
> ~/.emacs.d/ if he wants it.

I'm pretty sure I didn't create my ~/.emacs.d.  So the above doesn't seem to
be what Emacs currently aims for.  It looks like this directory is created
usually by the code which creates the ~/.emacs.d/auto-save-list directory.


        Stefan

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/14/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm pretty sure I didn't create my ~/.emacs.d.  So the above doesn't seem to
> be what Emacs currently aims for.

I think that currently Emacs doesn't aim for anything specific. Parts
do not use ~/.emacs.d/, others use it unconditionally, others
conditionally (like the ~/.emacs vs. ~/.emacs.d/init.el resolution).

What I'm proposing would be automatic if the fragments of code that
currently hardcode ~/.emacs.d/ (or, now, user-emacs-directory) were
changed to use user-emacs-file (or whatever the name).

It is not an important issue anyway; I'd prefer to defer to the user,
but both answers are OK.

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > On 6/14/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > 
 > > XEmacs has a whole API for finding user data.  The main function is
 > >
 > > (find-user-init-file &optional INIT-DIRECTORY HOME-DIRECTORY)
 > >
 > > Documentation:
 > > Determine the user's init file.
 > 
 > Could you please elaborate? (Or there is any way to find that
 > feature's docs, other than installing XEmacs?)

Not my place to elaborate; Mike designed it AFAIK.  For example, I
think your design which has the user name as an argument makes sense;
why Mike did *not* do it that way I don't know.  Please ask him.

If you want to look at docs, you'll probably want to install XEmacs.
It's consider internal to startup.el, and not documented in the Lisp
Reference according C-h C-f.  C-h a user.*file RET will give a list of
related functions; in XEmacs the preferred style is to provide
docstrings even for internal functions, so that's probably the best
we've got.

The Lisp Reference for XEmacs is available online at
http://www.xemacs.org/Documentation/.  Source for these APIs will be in

http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/lisp/startup.el?rev=1.58&content-type=text/vnd.viewcvs-markup

but internal evidence suggests that copyrights are not up-to-date and
I don't know Mike's code's assignment status, so you may wish to take
care when looking at that.

Re: Don't concat directories to file names

[Eli Zaretskii]

> Date: Thu, 14 Jun 2007 23:17:07 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> > IMO, if ~/.emacs.d does not exist, and it is what we prefer for the
> > future, we should create it here.
> 
> I'm not sure. I think the user should be responsible of creating
> ~/.emacs.d/ if he wants it.

We already create that directory in recover-session, so Tom's
suggestion makes a lot of sense to me.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> think your design which has the user name as an argument makes sense;

Well, the NAME in my function was not the user name, but the file
name; but the next stage on my plan was using the user name; that's
why I've been asking about ~USER/.emacs.d/ :)

> If you want to look at docs, you'll probably want to install XEmacs.
> It's consider internal to startup.el, and not documented in the Lisp
> Reference according C-h C-f.  C-h a user.*file RET will give a list of
> related functions; in XEmacs the preferred style is to provide
> docstrings even for internal functions, so that's probably the best
> we've got.

OK, I'll take a look.

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Eli Zaretskii <eliz@gnu.org> wrote:

> We already create that directory in recover-session, so Tom's
> suggestion makes a lot of sense to me.

Fine, then.

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/14/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> XEmacs has a whole API for finding user data.

If I'm undestanding it correctly, the API is for finding the user init
file (.emacs or _emacs or .emacs.el or whatever); I don't see a way to
determine where *other* configuration files should go. For example,
bookmark.el and saveplace.el both save their files to $HOME
(~/.emacs.bmk and ~/.emacs-places respectively).

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > If I'm undestanding it correctly, the API is for finding the user
 > init file (.emacs or _emacs or .emacs.el or whatever); I don't see
 > a way to determine where *other* configuration files should go.

XEmacs doesn't enforce it (we can't without imposing a gratuitous
incompatibility, since until now Emacs hasn't really had the concept),
but the variable `user-init-directory' is available to any library
that wants an Emacs-specific place to put things.  This is normally
initialized to "~/.xemacs" by startup.el.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> XEmacs doesn't enforce it (we can't without imposing a gratuitous
> incompatibility, since until now Emacs hasn't really had the concept),

Aha.

> but the variable `user-init-directory' is available to any library
> that wants an Emacs-specific place to put things.  This is normally
> initialized to "~/.xemacs" by startup.el.

Then the recently introduced `user-emacs-directory' should be renamed
to `user-init-directory', or aliased, I think (but it doesn't make
much sense to alias a just created var). The variable currently must
end with a directory separator, but that could be fixed.

But all in all, what I'm interested is having a public function so
modules that currently do

  (defvar my-module-setup-file "~/.my-module-data")

or

  (defvar my-module-setup-file
   (cond ((file-exists-p "~/.my-module-data") "~/.my-module-data")
         ((file-directory-p "~/.emacs.d/" "~/.emacs.d/my-module-setup"))
         (t ...)))

can be easily transformed to

  (defvar my-module-setup-file
   (user-emacs-file "my-module-data"  ; back-compatible
                    "my-module-setup" ; optional, default to above
                    ))

i.e. (it's a reworked version):

(defun user-emacs-file (name &optional new-name)
  "Convert NAME to an absolute per-user Emacs-specific path.
If \"~/NAME\" exists, or `user-emacs-directory' is nil, return \"~/NAME\".
Else, return \"`user-emacs-directory'/NEW-NAME\", or /NAME if NEW-NAME is nil."
  (convert-standard-filename
   (let ((at-home (expand-file-name name (concat "~" init-file-user))))
     (if (or (file-readable-p at-home)
             (null user-emacs-directory))
         at-home
       (or (file-accessible-directory-p (directory-file-name
user-emacs-directory))
           (progn (make-directory user-emacs-directory) t)  ;; don't
catch errors
           (expand-file-name (or new-name name) user-emacs-directory))))))

That function makes use of `user-emacs-directory' (that'd be
`user-init-directory', in XEmacs); uses `convert-standard-filename'
and, as requested, creates the ~/.emacs.d (~/.xemacs) directory on the
fly.

People wanting to use the same setup files in X?Emacs will have to
make user-(emacs|init)-directory point to the right place, or perhaps
set it to nil (and then `user-emacs-file' defers to ~/ and does not
try to create any dir).

WDYT?

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Then the recently introduced `user-emacs-directory' should be renamed
 > to `user-init-directory', or aliased, I think (but it doesn't make
 > much sense to alias a just created var). The variable currently must
 > end with a directory separator, but that could be fixed.

I think requiring the directory separator on the variable is
reasonable; after all, in most cases it will be determined implicitly
at startup or by a function call.  The trick of doing

(defun user-init-directory ()
  "Return the per-user directory holding Emacs configuration files."
  (if (and (boundp 'user-init-directory) 
           (file-directory-p user-init-directory))
      user-init-directory
    (find-user-init-directory)))  ; this may be oversimplified

is always available, too.

 > (defun user-emacs-file (name &optional new-name)
 >   "Convert NAME to an absolute per-user Emacs-specific path.
 > If \"~/NAME\" exists, or `user-emacs-directory' is nil, return \"~/NAME\".
 > Else, return \"`user-emacs-directory'/NEW-NAME\", or /NAME if NEW-NAME is nil."

Looks reasonable to me.  FWIW, existing XEmacs practice is to
encourage use of `user-init-directory' by looking there first (for our
startup files; we don't have the API you are proposing yet, so other
libraries have to code by hand).  Also, if ~/.emacs is found,
~/.xemacs/ doesn't exist, and migration is not inhibited, XEmacs
offers to migrate its files (.emacs and optionally custom.el) from
$HOME to `user-init-directory'.  If you say no, you get the option of
trying again later, or telling XEmacs not to bug you any more.

 > People wanting to use the same setup files in X?Emacs will have to
 > make user-(emacs|init)-directory point to the right place, or perhaps
 > set it to nil (and then `user-emacs-file' defers to ~/ and does not
 > try to create any dir).

XEmacs has -user-init-file and -user-init-directory options to handle
this (as well as the -u option).

I'm at my limit here: I can imagine use cases for all this
flexibility, but I've never encountered them in the wild.  I think
that `user-emacs-directory' and `user-init-directory' have similar
enough semantics that it would be nice if the variable name could be
the same.  I'd like to claim priority for `user-init-directory': it's
over ten years old in XEmacs.

Other than that, it's not at all obvious to me that any of XEmacs's
APIs or UIs in this area are used often enough to worry about
incompatibility.  I'm not a big fan of the name "user-emacs-file" for
the function you've defined; for me, even after all this time using
the ~/.xemacs/init.el style, I think it should point to ".emacs".  How
does "user-configuration-file" or "find-user-configuration-file"
sound?  (Of course "configuration" could be shortened to "config".)

Re: Don't concat directories to file names

[Stefan Monnier]

> Then the recently introduced `user-emacs-directory' should be renamed
> to `user-init-directory',

Indeed.  Please: could someone do that?

> The variable currently must end with a directory separator, but that could
> be fixed.

It should be fixed.  We should be careful to make it work with or without
a terminating / since it can be set by the user.  If we systematically use
it with expand-file-name, this will work automatically.

> (defun user-emacs-file (name &optional new-name)

If we rename the variable to user-init-directory, then the function should
probably be called user-init-file.

>  "Convert NAME to an absolute per-user Emacs-specific path.
> If \"~/NAME\" exists, or `user-emacs-directory' is nil, return \"~/NAME\".
> Else, return \"`user-emacs-directory'/NEW-NAME\", or /NAME if NEW-NAME is nil."
>  (convert-standard-filename
>   (let ((at-home (expand-file-name name (concat "~" init-file-user))))
>     (if (or (file-readable-p at-home)
>             (null user-emacs-directory))
>         at-home
>       (or (file-accessible-directory-p (directory-file-name
> user-emacs-directory))
>           (progn (make-directory user-emacs-directory) t)  ;; don't
> catch errors
>           (expand-file-name (or new-name name) user-emacs-directory))))))

In most places that introduced the ~/.emacs.d thingy, they typically first
check ~/.emacs.d/TOTO then ~/.TOTO and if neither is present return
~/.emacs.d/TOTO.


        Stefan

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> The trick of doing
>
> (defun user-init-directory ()
>   "Return the per-user directory holding Emacs configuration files."
>   (if (and (boundp 'user-init-directory)
>            (file-directory-p user-init-directory))
>       user-init-directory
>     (find-user-init-directory)))  ; this may be oversimplified

Yes, but that adds API complexity.

> Looks reasonable to me.  FWIW, existing XEmacs practice is to
> encourage use of `user-init-directory' by looking there first (for our
> startup files; we don't have the API you are proposing yet, so other
> libraries have to code by hand).

Yes, I looked at XEmacs' startup.el. But locating the startup files is
another issue; I'm interested in helping the libraries, not X?Emacs.

> I'm at my limit here: I can imagine use cases for all this
> flexibility, but I've never encountered them in the wild.

Agreed. Most of the API complexity of XEmacs (in this regard, I mean)
is for internal use, I think, so as you say below, compatibility is
not an issue IMO.

> I'd like to claim priority for `user-init-directory': it's
> over ten years old in XEmacs.

Of course!

> I'm not a big fan of the name "user-emacs-file" for
> the function you've defined

Neither do I; it was just to get going.

> How
> does "user-configuration-file" or "find-user-configuration-file"
> sound?  (Of course "configuration" could be shortened to "config".)

Good, I like `user-config-file' or `find-user-config-file'. Stefan has
proposed `user-init-file', but I don't like it because it seems
related to .emacs/init.el (as the variable of the same name is).

             Juanma

Re: Don't concat directories to file names

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Then the recently introduced `user-emacs-directory' should be renamed
>> to `user-init-directory',
>
> Indeed.  Please: could someone do that?

Er, well, "init" seems ... wrong.  It's used for more than "init files".

-miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Indeed.  Please: could someone do that?

I'll do, but lest first decide whether to add the new function,
because then many uses of `user-(init|emacs)-directory' will
disappear.

> It should be fixed.  We should be careful to make it work with or without
> a terminating / since it can be set by the user.  If we systematically use
> it with expand-file-name, this will work automatically.

Yes, that's what the-function-with-no-name-yet does.

> If we rename the variable to user-init-directory, then the function should
> probably be called user-init-file.

Too confusing, I think:

  user-init-file is a variable defined in `C source code'.
  Its value is
  "c:/usr/home/.emacs.d/init.el"

  Documentation:
  File name, including directory, of user's initialization file. [...]

> In most places that introduced the ~/.emacs.d thingy, they typically first
> check ~/.emacs.d/TOTO then ~/.TOTO and if neither is present return
> ~/.emacs.d/TOTO.

That's what the proposed function does, with the following differences:

 - It checks for ~/.TOTO before trying ~/.emacs.d/TOTO
 - It skips ~/.emacs.d/ altogether if the user explicitly sets
`user-emacs-directory' to nil.
 - It allows using TATA instead of TOTO in ~/.emacs.d/. The reason is
that things like .emacs-places seem ridiculous under ~/.emacs.d/; it's
better ~/.emacs.d/places than ~/.emacs.d/emacs-places.
 - It creates ~/.emacs.d/ when necessary (if ~/.TOTO does not exist, of course).

Is there something you feel should be different?

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/15/07, Miles Bader <miles@gnu.org> wrote:

> Er, well, "init" seems ... wrong.  It's used for more than "init files".

I agree, but it is a minor point and the name has prior art...

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > > The trick of doing
 > >
 > > (defun user-init-directory ()

 > Yes, but that adds API complexity.

Sure.  Since as Stefan points out it should be used in the context of
expand-file-name anyway, this can't really help, so I withdraw the
suggestion.

 > > How does "user-configuration-file" or
 > > "find-user-configuration-file" sound?  (Of course "configuration"
 > > could be shortened to "config".)
 > 
 > Good, I like `user-config-file' or `find-user-config-file'. Stefan has
 > proposed `user-init-file', but I don't like it because it seems
 > related to .emacs/init.el (as the variable of the same name is).

I agree.  I think the fact that there is a variable of that name with
a quite distinct meaning would be too confusing.

Re: Don't concat directories to file names

[Richard Stallman]

    >> Then the recently introduced `user-emacs-directory' should be renamed
    >> to `user-init-directory',
    >
    > Indeed.  Please: could someone do that?

    Er, well, "init" seems ... wrong.  It's used for more than "init files".

I agree.  "config" is also wrong; this is not just used for
configurations.  In fact, the current name `user-emacs-directory'
seems the best of those three.

    I agree, but it is a minor point and the name has prior art...

How so?

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/16/07, Richard Stallman <rms@gnu.org> wrote:

> I agree.  "config" is also wrong; this is not just used for
> configurations.  In fact, the current name `user-emacs-directory'
> seems the best of those three.

I'm not sure what to expect from a "user Emacs directory" either...
Perhaps `user-data-directory' would be vague enough.

>     I agree, but it is a minor point and the name has prior art...

Because, as Stephen has said, a variable with the same purpose and the
name `user-init-directory' has existed in XEmacs for ten years. Adding
the same variable with a different name is incompatibility for
incompatibility's sake; and more so because most uses of it will be
hidden after the proposed `find-user-config-file' function (with
whatever name).

             Juanma

Re: Don't concat directories to file names

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Er, well, "init" seems ... wrong.  It's used for more than "init files".
>
> I agree, but it is a minor point and the name has prior art...

So let's use the better name and add a variable-alias for xemacs
compability.

If the xemacs people also use the directory for more than init files,
they could even make the same change to their system
... variable-aliases are quite nice for backward compability!

-miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/16/07, Miles Bader <miles@gnu.org> wrote:

> If the xemacs people also use the directory for more than init files,
> they could even make the same change to their system
> ... variable-aliases are quite nice for backward compability!

I won't argue the point, but it seems to me a bit silly having to add
a new variable alias (and forcing the XEmacs people to add another)
just for that; more so when the variable didn't exist less than a week
ago (in Emacs).

And, all in all, `user-emacs-directory' is a bad name IMO.

             Juanma

Re: Don't concat directories to file names

[Stefan Monnier]

>>> Er, well, "init" seems ... wrong.  It's used for more than "init files".
>> I agree, but it is a minor point and the name has prior art...
> So let's use the better name and add a variable-alias for XEmacs
> compability.

I find it kind of silly, since user-emacs-directory is not
significantly better than user-init-directory.  The difference is rather
minor, so it seems pointless to waste all this time arguing and then adding
aliases for one name because the other is just a tad more unhelpful.


        Stefan

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/16/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The difference is rather
> minor, so it seems pointless to waste all this time arguing and then adding
> aliases for one name because the other is just a tad more unhelpful.

Agreed.

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Miles Bader writes:

 > If the xemacs people also use the directory for more than init files,
 > they could even make the same change to their system
 > ... variable-aliases are quite nice for backward compability!

Please don't.  For XEmacs, this variable is well-enough named that
there have been no questions and no complaints for about ten years.  I
see no reason why it will not serve Emacs equally well for the next
ten, even though it is perhaps suboptimal if there were no history.

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Richard Stallman writes:

 >     >> Then the recently introduced `user-emacs-directory' should be renamed
 >     >> to `user-init-directory',
 >     >
 >     > Indeed.  Please: could someone do that?
 > 
 >     Er, well, "init" seems ... wrong.  It's used for more than "init files".
 > 
 > I agree.  "config" is also wrong; this is not just used for
 > configurations.

The question is not how the directory is used; it is how the variable
is used.  To XEmacs-the-program, and its subsystems, the operational
meaning is "when you [re]*init*[ialize] the environment, the *user*'s
configuration files may be found in this *directory*."  This includes
the auto-autoloads for packages when the user cannot or prefers to not
install in the system load-path, for whatever reason.

True, if the auto-autoloads are there, then the rest of the package
(and infrastructure) are there too.  Many XEmacs users do things like
keep sources to private libraries and personal data files there, of
course.  But XEmacs and its subsystems know nothing about that!  They
find packaged code through `load-path', not `user-init-directory', and
they find data through `data-directory-list'.  So it seems
*preferable* that the variable name not indicate such usage.  Rather,
subsystems should use it to initialize standard paths so that `load'
and `locate-data-file' Just Work, rather than have subsystems
explicitly referencing `user-emacs-directory'.

If Emacs's use is going to be substantially different, please pick an
appropriate name for that.  But as I understand it, the primary usage
of this *variable* is going to be finding user configuration when
initializing Emacs and its subsystems, as it described above for XEmacs.

Re: Don't concat directories to file names

[Richard Stallman]

    I'm not sure what to expect from a "user Emacs directory" either...

The user's directory for Emacs-specific purposes.

    Perhaps `user-data-directory' would be vague enough.

That fails to make the point, so it is not as good.

    Because, as Stephen has said, a variable with the same purpose and the
    name `user-init-directory' has existed in XEmacs for ten years.

I don't think anyone will care if they are different, but if so,
someone can make an alias.

Re: Don't concat directories to file names

[Richard Stallman]

    The question is not how the directory is used; it is how the variable
    is used.  To XEmacs-the-program, and its subsystems, the operational
    meaning is "when you [re]*init*[ialize] the environment, the *user*'s
    configuration files may be found in this *directory*."

The names `emacs-config-directory' or `emacs-init-directory' seem to
fit what XEmacs does.  In Emacs, the directory is used for many other
things, including auto-saving.  So that name is not appropriate in
Emacs.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/16/07, Richard Stallman <rms@gnu.org> wrote:

> I don't think anyone will care if they are different, but if so,
> someone can make an alias.

Obviously Stephen cares, or he would not have asked us to respect
their prior name. FWIW, I agree with it.

But the naming of the variable is not what concerns me more; what I
want to know is whether it is OK to install the function I proposed,
and with what name.

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On 6/16/07, Richard Stallman <rms@gnu.org> wrote:
 > 
 > > I don't think anyone will care if they are different, but if so,
 > > someone can make an alias.
 > 
 > Obviously Stephen cares,

Not any more.  Just get the function in, please.

Re: Don't concat directories to file names

[Stefan Monnier]

>     Because, as Stephen has said, a variable with the same purpose and the
>     name `user-init-directory' has existed in XEmacs for ten years.

> I don't think anyone will care if they are different, but if so,
> someone can make an alias.

I do care.  So do a few others on this list.  Brashly ignoring XEmacs prior
use is unlikely to help us reduce the unnecessary and destructive tension
between the two communities.


        Stefan

Re: Don't concat directories to file names

[Richard Stallman]

    > I don't think anyone will care if they are different, but if so,
    > someone can make an alias.

    I do care.  So do a few others on this list.

Can you present a reason why it matters whether this variable has the
same name in Emacs and XEmacs?  Which programs would need such
compatibility?

Re: Don't concat directories to file names

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > I don't think anyone will care if they are different, but if so,
>     > someone can make an alias.
>
>     I do care.  So do a few others on this list.
>
> Can you present a reason why it matters whether this variable has the
> same name in Emacs and XEmacs?  Which programs would need such
> compatibility?

All packages needing a place for package-specific
initialization/configuration/data files?

-- 
David Kastrup

Re: Don't concat directories to file names

[Richard Stallman]

    All packages needing a place for package-specific
    initialization/configuration/data files?

I thought we were going to create a function for them to use.  That
function doesn't exist in XEmacs.  Let's pick the best name for it.
if XEmacs wants to add that function, it can use the best name too.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/20/07, Richard Stallman <rms@gnu.org> wrote:

> I thought we were going to create a function for them to use.

Yes. It is waiting for you to OK a name (I hate commiting code and
changing names a few days later).

> Let's pick the best name for it.

Stephen proposed `user-config-file' or `find-user-config-file', and I
like them, but I think you said it is not only for configuration
files. So, some permutation of `user', `local, `data' and `directory'.

What about the variable `user-emacs-directory'? That is surely not the
"best name for it".

Perhaps we could name the variable `user-data-directory' and the
function `find-user-data-file'.

             Juanma

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Perhaps we could name the variable `user-data-directory' and the
 > function `find-user-data-file'.

That name for the variable is fine with me.  The user-init-directory
can continue to have the semantics we've used to date, and
user-data-directory will probably default to that in XEmacs.

Regarding `find-user-data-file', XEmacs distinguishes between
"locating" a file (those functions return file names), and "finding" a
file (those functions switch to a buffer visiting the file).  I forget
which your function does....  I don't have a strong feeling about
this, but Emacs makes a similar distinction with "find-library"
vs. "locate-library".  Maybe it's worth being consistent?

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/20/07, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Regarding `find-user-data-file', XEmacs distinguishes between
> "locating" a file (those functions return file names), and "finding" a
> file (those functions switch to a buffer visiting the file).  I forget
> which your function does....

It's a locate-style function: it returns the path of a
conf/initialization/persitent-data file.

I don't have a strong feeling about
> this, but Emacs makes a similar distinction with "find-library"
> vs. "locate-library".  Maybe it's worth being consistent?

Emacs has `locate-library', `locate-file' and `locate-data-directory'.
Perhaps `locate-user-data' would make sense.

             Juanma

Re: Don't concat directories to file names

[Richard Stallman]

    Regarding `find-user-data-file', XEmacs distinguishes between
    "locating" a file (those functions return file names), and "finding" a
    file (those functions switch to a buffer visiting the file).  I forget
    which your function does....  I don't have a strong feeling about
    this, but Emacs makes a similar distinction with "find-library"
    vs. "locate-library".  Maybe it's worth being consistent?

I agree with that point.

But I still don't like `data'.  All the user's directories
hold the user's data, not just this one.

Re: Don't concat directories to file names

[Richard Stallman]

    Stephen proposed `user-config-file' or `find-user-config-file', and I
    like them, but I think you said it is not only for configuration
    files. So, some permutation of `user', `local, `data' and `directory'.

    What about the variable `user-emacs-directory'? That is surely not the
    "best name for it".

It is the best of all the names suggested so far.
What these files all have in common is that they are used
in special ways by Emacs.

The function could be `locate-user-emacs-directory'

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Richard Stallman writes:

 >     What about the variable `user-emacs-directory'? That is surely not the
 >     "best name for it".
 > 
 > It is the best of all the names suggested so far.

*sigh*  For the record, I disgree strongly.  All of the other names
suggested so far are better.  This one has no intuitive meaning to me,
except "the directory where I keep .emacs".  That already has a
reasonably expressive name with a decade of history in XEmacs:
`user-init-directory'.

Re: Don't concat directories to file names

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> But I still don't like `data'.  All the user's directories
> hold the user's data, not just this one.

Compare the variable data-directory.  user-data-directory would be like
data-directory, except for the user.

(I don't think that the name data-directory suggests that all data is in
that directory, only that the Emacs data files are in that directory.
By a similar token, user-init-file doesn't suggest that all the user's
initialization is in that file, only the Emacs initialization.)

Kai

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/21/07, Richard Stallman <rms@gnu.org> wrote:

> What these files all have in common is that they are used
> in special ways by Emacs.

Which is so generic as to not mean anything IMO.

> The function could be `locate-user-emacs-directory'

The function does not locate a directory, but a file. It's intended to
return the path for a filename, i.e., if a module wants to save its
data in ".my-module" and your $HOME is /home/you, and
`user-emacs-directory' is at default value, then

 (function-without-a-name ".my-module")

will return "/home/you/.my-module" if it exists, else
"/home/you/.emacs.d/.my-module" (creating /home/you/.emacs.d/ as
needed).

With the second optional argument NEW-NAME:

 (function-without-a-name ".my-module" "module-data")

in the second case (when ~/.my-module does not exist) it will return
"/home/you/.emacs.d/module-data".

So locate-user-emacs-directory does not describe what the function
does, and locate-user-emacs-file would be confusing: it does not
return the path of the "emacs file" (presumable .emacs).

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/21/07, Kai Grossjohann <kai@emptydomain.de> wrote:

> Compare the variable data-directory.  user-data-directory would be like
> data-directory, except for the user.

That was the idea.

> (I don't think that the name data-directory suggests that all data is in
> that directory, only that the Emacs data files are in that directory.

Agreed.

             Juanma

Re: Don't concat directories to file names

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> So locate-user-emacs-directory does not describe what the function
> does, and locate-user-emacs-file would be confusing: it does not
> return the path of the "emacs file" (presumable .emacs).

locate-user-file ?  locate-user-emacs-file could have the file name
argument optional, defaulting to .emacs/init.el or something.

-- 
David Kastrup

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/21/07, David Kastrup <dak@gnu.org> wrote:

> locate-user-file ?

Fine by me. Then we could name the variable `user-files-directory'...
I think we all can agree that directory is going to contain files :)
(but I still like user-data-directory much, much more.)

> locate-user-emacs-file could have the file name
> argument optional, defaulting to .emacs/init.el or something.

I purposely didn't care about .emacs in my function, though you could
get the basic functionality with

  (function-without-a-name ".emacs" "init.el")

because the .emacs case is quite specific. On MS-DOS/Windows, NAME has
four possible values and can be found in at least three places. You
could generalize the function-without-a-name to accept a predicate or
something, but it's not worth the complexity just for this case.

             Juanma

Re: Don't concat directories to file names

[Richard Stallman]

    Compare the variable data-directory.  user-data-directory would be like
    data-directory, except for the user.

Ok, I will agree to `user-data-directory'.

    > What these files all have in common is that they are used
    > in special ways by Emacs.

    Which is so generic as to not mean anything IMO.

Exactly -- the only thing they have in common is having a special
relationship to Emacs.

    > The function could be `locate-user-emacs-directory'

    The function does not locate a directory, but a file.

In that case, both `locate-user-XYZ-directory' and `find-user-XYZ-directory'
are bad names for it.

							  It's intended to
    return the path for a filename, i.e., if a module wants to save its
    data in ".my-module" and your $HOME is /home/you, and
    `user-emacs-directory' is at default value, then

     (function-without-a-name ".my-module")

    will return "/home/you/.my-module" if it exists, else
    "/home/you/.emacs.d/.my-module" (creating /home/you/.emacs.d/ as
    needed).

I suggest the name `locale-emacs-data-file'.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/22/07, Richard Stallman <rms@gnu.org> wrote:

> Ok, I will agree to `user-data-directory'.

Great, thanks.

> Exactly -- the only thing they have in common is having a special
> relationship to Emacs.

My point was that saying that they have a special relationship with
Emacs is equally generic.

> In that case, both `locate-user-XYZ-directory' and `find-user-XYZ-directory'
> are bad names for it.

Yes. I was suggesting something with -file.

> I suggest the name `locale-emacs-data-file'.

Going with the `user-data-directory' theme, I think it's better
`locate-user-data-file'.

             Juanma

Re: Don't concat directories to file names

[Richard Stallman]

    > Exactly -- the only thing they have in common is having a special
    > relationship to Emacs.

    My point was that saying that they have a special relationship with
    Emacs is equally generic.

It is supposed to be generic.  Most of your files don't have any
special relationship with Emacs.  You might edit them with Emacs but
they don't exist for the sake of using Emacs.  These files do exist
for the sake of using Emacs.

Re: Don't concat directories to file names

[Richard Stallman]

    Yes. I was suggesting something with -file.

    > I suggest the name `locale-emacs-data-file'.

    Going with the `user-data-directory' theme, I think it's better
    `locate-user-data-file'.

I think `locate-emacs-data-file is better because it expresses the
fact that you're looking for data files that relate specially to
Emacs.

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/22/07, Richard Stallman <rms@gnu.org> wrote:

> I think `locate-emacs-data-file is better because it expresses the
> fact that you're looking for data files that relate specially to
> Emacs.

Well, in fact I said that the function does not return a directory,
and that's true, it returns a path. However, sometimes that path is a
directory name, as when a module uses it to construct a directory to
put temporary files.

So, following your suggestion it'd be more like
`locate-emacs-data-path'. Which I dislike, because we're insisting on
Emacs (which I think we can assume) and we're neglecting the user.
`locate-user-data-path' seems more to the point.

But at this point, I just want to commit it. Please, choose one.

             Juanma

Re: Don't concat directories to file names

[Stefan Monnier]

> Well, in fact I said that the function does not return a directory,
> and that's true, it returns a path.

No: a path is a list of directories (as in the PATH, MANPATH EMACSLOADPATH,
etc...).  What it returns is a file name.  The file referenced may be of
directory kind (or symlink kind, or normal file kind, or even device kind),
but it's still a file name.


        Stefan

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/25/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> No: a path is a list of directories (as in the PATH, MANPATH EMACSLOADPATH,
> etc...).

You're right.

> What it returns is a file name.  The file referenced may be of
> directory kind (or symlink kind, or normal file kind, or even device kind),
> but it's still a file name.

It's not the first time I mix the terminology (Richard corrected me a
couple times before). I've honestly tried to remember it, but my mind
refuses, perhaps as a rection to the horror of supposing that
everything is a file, which a directory is not (in general, though I
know it *is* in Unix and its derivatives, and many other OSes). I'm
not going to enter an OS flamewar, but in my younger days I hacked
VAX/VMS, where a filename and a directory were clearly distinct :)

I understand (and promptly forget, alas) how "path" is used in Emacs.
But I unconsciously revert to the more widespread use, as documented
in the Wikipedia, among many other places: "A path is the general form
of a file or directory name, giving a file's name and its unique
location in a file system." The use of path brought to life from PATH
and other environment variables is an accident that would've been
averted had the original namer had the forethought of calling it
PATHS, which seems more logical...

At least I didn't find difficult to remember that frames are windows
and windows are panes (and yeah, I know, Emacs Was There First :)

locate-user-emacs-file, then, as ugly as it is.

             Juanma

Re: Don't concat directories to file names

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> At least I didn't find difficult to remember that frames are windows
> and windows are panes (and yeah, I know, Emacs Was There First :)
>
> locate-user-emacs-file, then, as ugly as it is.

>From functions like file-name-as-directory and directory-file-name one
could possibly derive locate-user-emacs-file-name.  However, I find
that this sounds illogical since the _name_ is not what is _located_.

So locate-*-file seems more appropriate.

-- 
David Kastrup

Re: Don't concat directories to file names

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> At least I didn't find difficult to remember that frames are windows
>> and windows are panes (and yeah, I know, Emacs Was There First :)
>>
>> locate-user-emacs-file, then, as ugly as it is.
>
>>From functions like file-name-as-directory and directory-file-name one
> could possibly derive locate-user-emacs-file-name.  However, I find
> that this sounds illogical since the _name_ is not what is _located_.
>
> So locate-*-file seems more appropriate.

Actually, in correspondence with `make-temp-name', the function might
be named `make-user-file-name'.  The disadvantage is that `make'
carries with it the slight connotation that the file and/or name will
be a new one.  That would be somewhat alleviated by using
`get-user-file-name' (get is used in a similar function with buffers).

I think I should stop now before someone shoots me.

-- 
David Kastrup

Re: Don't concat directories to file names

[Richard Stallman]

    Well, in fact I said that the function does not return a directory,
    and that's true, it returns a path.

The GNU Project convention is to use the term "path" only to mean a
list of directories to search.  For what this function returns,
our term is "file name".

Re: Don't concat directories to file names

[Stefan Monnier]

> I'm not going to enter an OS flamewar, but in my younger days I hacked
> VAX/VMS, where a filename and a directory were clearly distinct :)

Emacs follows this idea as well.  I.e. a directory is a file, and it has two
names: one to treat it as a filem and another to treat it as a directory.
So /usr is a directory whose file name is "/usr" and directory name is
"/usr/", see file-name-as-directory and directory-file-name.

Unider Unix, the trailing slash often makes no difference, so people tend to
forget about the distinction, but occasionally the difference is significant.


        Stefan

Re: Don't concat directories to file names

[Stefan Monnier]

> couple times before).  I've honestly tried to remember it, but my mind
> refuses, perhaps as a rection to the horror of supposing that
> everything is a file, which a directory is not (in general, though I

Not everything is a file.  But a directory is a file on all OSes I know that
includes VMS).


        Stefan

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/25/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Emacs follows this idea as well.  I.e. a directory is a file, and it has two
> names: one to treat it as a filem and another to treat it as a directory.
> So /usr is a directory whose file name is "/usr" and directory name is
> "/usr/", see file-name-as-directory and directory-file-name.

I know, I'm even using `directory-file-name' in The Function Without A
Name. But Emacs users and developers apparently don't, if they don't
balk at the idea of a function *-file returning the path (cough, the
filename, I mean) of a directory.

             Juanma

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/25/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Not everything is a file.  But a directory is a file on all OSes I know that
> includes VMS).

I must be misremembering VMS. Neither at the command prompt nor in the
programming API were directories treated as files IIRC.

Also, in MS-DOS, there was some trickery to simulate that directories
were files, but you couldn't, for example, get the size of one, or
directly write onto it as a file. At least that's what I remember of
some distant past.

             Juanma

Re: Don't concat directories to file names

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 6/25/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> Emacs follows this idea as well.  I.e. a directory is a file, and it has two
>> names: one to treat it as a filem and another to treat it as a directory.
>> So /usr is a directory whose file name is "/usr" and directory name is
>> "/usr/", see file-name-as-directory and directory-file-name.
>
> I know, I'm even using `directory-file-name' in The Function Without A
> Name. But Emacs users and developers apparently don't, if they don't
> balk at the idea of a function *-file returning the path (cough, the
> filename, I mean) of a directory.

That's why we have file-name-as-directory, isn't it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Don't concat directories to file names

[Juanma Barranquero]

On 6/25/07, David Kastrup <dak@gnu.org> wrote:

> That's why we have file-name-as-directory, isn't it?

To placate your consciences, you mean?

             Juanma

Re: Don't concat directories to file names

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Also, in MS-DOS, there was some trickery to simulate that directories
> were files, but you couldn't, for example, get the size of one, or
> directly write onto it as a file.

You can't write to a directory file on Unix either, and the size of it
is mostly meaningless too.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Don't concat directories to file names

[Eli Zaretskii]

> Date: Mon, 25 Jun 2007 20:27:30 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Also, in MS-DOS, there was some trickery to simulate that directories
> were files, but you couldn't, for example, get the size of one, or
> directly write onto it as a file.

Directories _are_ files on MSDOS, they are just special files, in that
some file I/O functions fail for them.

Re: Don't concat directories to file names

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 25 Jun 2007 20:27:30 +0200
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: rms@gnu.org, emacs-devel@gnu.org
>> 
>> Also, in MS-DOS, there was some trickery to simulate that directories
>> were files, but you couldn't, for example, get the size of one, or
>> directly write onto it as a file.
>
> Directories _are_ files on MSDOS, they are just special files, in that
> some file I/O functions fail for them.

I seem to remember that the root directory on a disk is not a file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Don't concat directories to file names

[Eli Zaretskii]

> Cc: "Juanma Barranquero" <lekktu@gmail.com>,  emacs-devel@gnu.org,
> 	  monnier@iro.umontreal.ca,  rms@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Mon, 25 Jun 2007 22:39:20 +0200
> 
> > Directories _are_ files on MSDOS, they are just special files, in that
> > some file I/O functions fail for them.
> 
> I seem to remember that the root directory on a disk is not a file.

I think in later versions it was a file.

Re: Don't concat directories to file names

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > I know, I'm even using `directory-file-name' in The Function Without A
 > Name. But Emacs users and developers apparently don't, if they don't
 > balk at the idea of a function *-file returning the path (cough, the
 > filename, I mean) of a directory.

It's not globally consistent, of course.

As with many other concepts in Emacs there is a confusion between
objects, names for objects, and handles (references) to objects.
Consider fonts and coding systems.  (XEmacs actually has font objects
and coding system objects, but I have yet to see a case where the
distinction between a symbol naming such an object and the actual
object is useful.)

Consider that Emacs doesn't have a notion of file handle.  What serves
for a file handle in Emacs is a buffer visiting a file.  Thus the
distinction between the verbs "find" and "locate", which serves the
same kind of purpose with complete different syntax.

I don't mean to argue that you're "wrong" (how could you be?  this is
definitely a YMMV kinda thang :-).  Nor does this directly address the
PATH-style path vs. URL-style path issue.  This helps me to
rationalize it, that's all.