[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dired-compare-directories
From: |
Juri Linkov |
Subject: |
Re: dired-compare-directories |
Date: |
Mon, 28 Mar 2005 02:45:45 +0300 |
User-agent: |
Gnus/5.110002 (No Gnus v0.2) Emacs/22.0.50 (gnu/linux) |
> I do not know whether anything relies on this behavior, but before
> making any incompatible change this close before a release, one would
> better be really extra careful.
`read-directory-name' inherits its current behavior from `read-file-name'.
The Emacs manual says:
If DEFAULT is `nil', `read-file-name' tries to find a substitute
default to use in its place, which it treats in exactly the same
way as if it had been specified explicitly. If DEFAULT is `nil',
but INITIAL is non-`nil', then the default is the absolute file
name obtained from DIRECTORY and INITIAL. If both DEFAULT and
INITIAL are `nil' and the buffer is visiting a file,
`read-file-name' uses the absolute file name of that file as
========================================
default. If the buffer is not visiting a file, then there is no
default. In that case, if the user types <RET> without any
editing, `read-file-name' simply returns the pre-inserted contents
========================================
of the minibuffer.
Silently using the absolute file name is a very error-prone behavior.
There was a bug report recently about `copy-file' and other similar
command assuming a wrong filename. This was fixed by introducing
a new interactive specifier "G" (which is not mnemonic). I think this
workaround was a mistake. `read-file-name' (and `read-directory-name')
with nil DEFAULT should not return a filename not explicitly
specified by the user in the minibuffer. They should return the
pre-inserted contents, unless specially programmed to return something
else by specifying the non-nil DEFAULT argument.
--
Juri Linkov
http://www.jurta.org/emacs/