Re: Updated project-specific settings patch

[David Kastrup]

Miles Bader <address@hidden> writes:

> Michael Olson <address@hidden> writes:
>> I've applied this patch.  I modified it to go back to the old behavior
>> of using concat, however, because there were some objections to using
>> expand-file-name here, and I don't like calling expand-file-name where
>> it's not really needed.
>
> "Some objections"?
>
> Concat is generally not the right thing for handling filenames;

Why?

> if there are concrete problems with expand-file-name, they should be
> addressed.

I already said that expand-file does ~ expansion which may not be
wanted.

And we have

file-name-directory is a built-in function in `C source code'.

(file-name-directory FILENAME)

Return the directory component in file name FILENAME.
Return nil if FILENAME does not include a directory.
Otherwise return a directory name.
Given a Unix syntax file name, returns a string ending in slash;
on VMS, perhaps instead a string ending in `:', `]' or `>'.

[back]

"directory component" very much sounds like it is a direct substring.

And

file-name-nondirectory is a built-in function in `C source code'.

(file-name-nondirectory FILENAME)

Return file name FILENAME sans its directory.
For example, in a Unix-syntax file name,
this is everything after the last slash,
or the entire name if it contains no slash.

[back]

also very much sounds like it is a substring.

So why wouldn't one expect

(string= f (concat (file-name-directory f) (file-name-nondirectory f)))

to hold?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum