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: Q on read-file-name and completion-ignored-extensions Date: Wed, 18 Jan 2006 17:45:28 -0800 Message-ID: References: <87irshm35u.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137636251 30910 80.91.229.2 (19 Jan 2006 02:04:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 19 Jan 2006 02:04:11 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 19 03:04:10 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EzP9j-0000Ko-AX for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2006 03:04:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzPC8-0008Kh-Rt for ged-emacs-devel@m.gmane.org; Wed, 18 Jan 2006 21:06:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EzOuY-00033O-FI for emacs-devel@gnu.org; Wed, 18 Jan 2006 20:48:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EzOuI-0002li-G5 for emacs-devel@gnu.org; Wed, 18 Jan 2006 20:48:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EzOuI-0002lF-6u for emacs-devel@gnu.org; Wed, 18 Jan 2006 20:48:10 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EzOyD-0000Uw-9Y for emacs-devel@gnu.org; Wed, 18 Jan 2006 20:52:14 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k0J1jV6i008785 for ; Wed, 18 Jan 2006 18:45:31 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0J1jVDk007770 for ; Wed, 18 Jan 2006 18:45:31 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-106-66.vpn.oracle.com [141.144.106.66]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0J1jU8L007761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 18 Jan 2006 18:45:30 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <87irshm35u.fsf-monnier+emacs@gnu.org> Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:49252 Archived-At: > Type the beginning of the name of one of the .el files - e.g. > app, then TAB. I see all files starting with "app" in > *Completions*, including .el files. Yes, that's the intended behavior. Thanks for the confirmation. The docstring says: This variable does not affect lists of possible completions, but does affect the commands that actually do completions. Here, you're parroting what I said in my first post, where I quoted the same doc string. That doc string contradicts the `read-file-name' behavior, at least by my reading of it. You say "it works", but by my reading it doesn't work, as I pointed out: `minibuffer-complete' is a "command that actually does completion", but it does not respect this variable when you use it in the context of `read-file-name'. Apparently, sometimes such commands are affected by the variable and other times they are not. Based on your confirmation, I repeat what I said initially: If the current behavior is by design, then perhaps the doc string should say something about this case. I'm not sure what it should say, because I don't know if `read-file-name' is the only exception to letting "commands that actually do completion" respect the variable. By "commands that actually do completion", I assume is meant commands such as `minibuffer-complete' (TAB), `minibuffer-complete-and-exit' (RET), and `minibuffer-complete-word' (SPC). If that's not correct, then please explain what is meant (that should also be done in the doc string, in that case). `read-file-name' is neither a command that does completion nor does it provide a list of possible completions, so the current doc string does not address its case at all, directly. However, you can use commands that complete input while inputting a file name to `read-file-name'. In this case, those commands do _not_ act as the doc string says they should - they do not respect the variable (be "affected" by its value). IOW, `read-file-name' is an exception to the behavior expressed by the doc string (an exception by design, according to your confirmation). If `read-file-name' is the only such exception, then it should be called out in the doc string as a special case: Commands that complete minibuffer input respect this variable, except for input to `read-file-name'. This variable also does not affect lists of possible completions. If `read-file-name' is not the only such exception, then something else should be said, which characterizes the cases where completion commands do and do not respect this variable. The phrase "lists of possible completions" could profitably be clarified as well. I suppose it means functions like `all-completions', but I'm not sure, as it's not very clear.