From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: read-file-name-predicate Date: Wed, 7 Mar 2007 08:31:59 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1173285240 28856 80.91.229.12 (7 Mar 2007 16:34:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 7 Mar 2007 16:34:00 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 07 17:33:50 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HOz5F-0007U8-S5 for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2007 17:33:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HOz5M-0001Cy-4f for ged-emacs-devel@m.gmane.org; Wed, 07 Mar 2007 11:33:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HOz5B-0001Ct-Q2 for emacs-devel@gnu.org; Wed, 07 Mar 2007 11:33:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HOz58-0001Ch-Bu for emacs-devel@gnu.org; Wed, 07 Mar 2007 11:33:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HOz58-0001Ce-7b for emacs-devel@gnu.org; Wed, 07 Mar 2007 11:33:38 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HOz50-0006fw-Q3 for emacs-devel@gnu.org; Wed, 07 Mar 2007 11:33:31 -0500 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l27GXSam004398 for ; Wed, 7 Mar 2007 09:33:28 -0700 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l27FdodX009665 for ; Wed, 7 Mar 2007 09:33:25 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by rcsmt250.oracle.com with ESMTP id 2503199351173285119; Wed, 07 Mar 2007 09:31:59 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67509 Archived-At: > > Being visible from Lisp doesn't mean it's external. Lots of=20 > > 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"...) =20 > 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.