RE: read-file-name-predicate

["Drew Adams" <drew.adams@oracle.com>]

> > Being visible from Lisp doesn't mean it's external.  Lots of 
> > elisp packages have internal variables as well.

So substitute "accessible from Lisp" where you feel I mispoke by using "external". I was trying to contrast internal to C with accessible from Lisp. (One level's "internal" is another level's "external"...)
 
> You're right, but I suppose Drew's point is: why it is visible from
> Lisp *at all*? It is not used anywhere from lisp/*.el, and the only
> src/* to use it is fileio.c.

My point is that it is currently entre deux chaises. Either 1) it should be, as it is, accessible from Lisp, in which case it should be documented, or 2) it should be inaccessible from Lisp. (Yes, I do realize that not everything that is accessible from Lisp is documented.)

I personally prefer #1. This being accessible from Lisp is a useful feature. I already use it in one of my libraries in a way similar to using `minibuffer-completion-predicate. I think that these two variables should in fact be treated in the same way: keep them accessible from Lisp, and document them similarly.

> I see Kim added it relatively recently, along with
> read-file-name-function, which is used in ido. Perhaps he had some
> intended use in mind?

I don't know what use Kim intended originally, but I've found it useful. Accessing `minibuffer-completion-predicate' is useless when it comes to file-name completion, and `read-file-name-predicate' fills the bill nicely. Without it, I know of no way to get at that predicate during completion, either to examine it or to modify it.