Re: Reading directory names with read-file-name

[storm@cua.dk (Kim F. Storm)]

Richard Stallman <rms@gnu.org> writes:

>     How about allowing READ-DIR to be any predicate, so that the invoker
>     of read-file-name can filter file names in arbitrary ways?
> 
> This could be made consistent with the new locate-file function.
> 
>       I suspect
>     that this would subsume read-file-name's existing MUSTMATCH argument
>     to some extent, since MUSTMATCH=t would be roughly equivalent to
>     READ-DIR=file-exists-p, but I can't think of a cleaner extension
>     offhand.
> 
> This suggests that we should redefine the MUSTMATCH argument
> rather than add a new one.

There is one major difficult here:

The doc string states:

Fourth arg MUSTMATCH non-nil means require existing file's name.
 Non-nil and non-t means also require confirmation after completion.

I've looked through the *.el files, and I've found at least the
following non-nil and non-t values:
    lambda, confirm, must-match, yes

It seems difficult to me to extend the MUSTMATCH argument to cover
both a predicate and the current tri-state behaviour, and do it
in a way which is compatible with locate-file.

It could be a cons (PREDICATE . MUSTMATCH), but in that case, I
thing adding a sixth argument PREDICATE to read-file-name is
simpler.

The predicate need to be passed on the read-file-name-internal, but as
Stefan points out, this is difficult since the predicate argument is
already used for the directory.  Since read-file-name-internal is
overridden by several packages, I don't think changing that API 
is feasible.

Instead, read-file-name could specbind read-file-name-predicate
to the predicate argument, and read-file-name-internal could check
that predicate.

It could also be considered to add a third argument PREDICATE
to file-name-all-completions.


I'm not sure how to proceed.  Please advise!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk