Re: read-directory-name, the unloved

[Antoine Levitt]

12/02/11 15:44, Andreas Schwab
> Antoine Levitt <address@hidden> writes:
>
>> Read-directory-name is basically a wrapper on read-file-name, using
>> file-directory-p as PREDICATE. So if anything else, read-directory-name
>> is more restrictive than read-file-name. In any case, since MUSTMATCH
>> is nil, there's no obligation to choose a real file/directory, so
>> PREDICATE is only used for completion purposes.
>
> dired accepts more than just a directory as argument, and I would be
> annoyed if I would not be able complete a non-directory.
>
> Andreas.

Ah, sorry, I missed that. I guess the point is to get a dired view of
for instance some_long_name.1, some_long_name.2, etc., so you'd do C-x d
some TAB * RET? Then the unpatched code was perfectly fine, and ido
users don't care anyway since it's wrapped by ido. Apologies, and thanks
for pointing that out. Here's a patch with comments to clarify that
situation.

--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -604,6 +604,8 @@ Don't use that together with FILTER."
            ;; If a dialog is about to be used, call read-directory-name so
            ;; the dialog code knows we want directories.  Some dialogs can
            ;; only select directories or files when popped up, not both.
+           ;; If no dialog is used, call read-file-name because the user may
+           ;; want completion of file names for use in a wildcard pattern.
            (if (next-read-file-uses-dialog-p)
                (read-directory-name (format "Dired %s(directory): " str)
                                     nil default-directory nil)