emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: load-path contains directories or directory names?


From: Eli Zaretskii
Subject: Re: load-path contains directories or directory names?
Date: Sun, 25 Oct 2015 20:39:21 +0200

Potential bikeshedding alert!

> From: Stephen Leake <address@hidden>
> Date: Sat, 24 Oct 2015 16:46:19 -0500
> Cc: address@hidden
> 
> "John Wiegley" <address@hidden> writes:
> 
> >>>>>> Michael Heerdegen <address@hidden> writes:
> >
> >> I try to avoid string operations on file names.
> >> In the above case, using
> >>   (expand-file-name name dir)
> >> seems cleaner to me.

I'm with John on this one, see below for reasons.

> (info "(elisp) Directory Names" says to use:
> 
> (concat DIRNAME RELFILE)

No, it says you CAN use that.  And it continues:

  Be sure to verify that the file name is relative before doing that.  If
  you use an absolute file name, the results could be syntactically
  invalid or refer to the wrong file.

which all but explains why using 'concat' is less desirable than using
'expand-file-name': the code will be more complicated because it needs
to call another function if the directory name doesn't end in a slash.

Also, 'expand-file-name' transparently treats a nil correctly.

In addition, on MS-Windows 'expand-file-name' converts all backslashes
to forward slashes, thus producing nicer and more "standard" results.

> So if I'm iterating thru a path that is defined to contain directory
> names (as `load-path' is, but see other email), this code is correct:
> 
> (concat dir name)
> 
> However, if the path contains directory file names (as
> `load-path' is implemented), then this code is correct:
> 
> (concat (file-name-as-directory dir) filename)
> 
> However, `file-name-as-directory' tolerates ending slashes or not in
> `dir', so the latter code is robust against people putting the wrong
> things in the path.
> 
> Same for `expand-file-name' of course.

Exactly.  So I think 'expand-file-name' is a (slightly) better
alternative in these cases.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]