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: Entering filenames with spaces Date: Sat, 5 Nov 2005 08:34:44 -0800 Message-ID: References: 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 1131208616 4355 80.91.229.2 (5 Nov 2005 16:36:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2005 16:36:56 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 05 17:36:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EYR0u-0006Uw-QQ for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2005 17:35:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EYR0t-0006el-Fz for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2005 11:35:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EYR0K-0006eU-Gh for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:34:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EYR0I-0006eA-RS for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:34:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EYR0I-0006e7-Iv for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:34:54 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EYR0I-0006xn-IL for emacs-devel@gnu.org; Sat, 05 Nov 2005 11:34:54 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA5Gj9kn020820 for ; Sat, 5 Nov 2005 10:45:09 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA5GYqOs002980 for ; Sat, 5 Nov 2005 09:34:52 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-72-186.vpn.oracle.com [141.144.72.186]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id jA5GYopC002961 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 5 Nov 2005 09:34:52 -0700 Original-To: 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.2800.1506 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:45462 Archived-At: On 19 Oct 2005, at 03:43, Richard M. Stallman wrote: > > Does a filename-minibuffer have an extra keymap? > > Not at present, but giving it its own keymap is the cleanest > way to do this job. OK, this is a simple patch now which allows for inputting spaces in filenames in the minibuffer, while keeping the binding of space to minibuffer-complete-word in other contexts. It introduces a new keymap, minibuffer-local-filename-completion-map. Was this a final decision? If not, let me stir the pot a bit one more time. Although I argued previously for the utility of SPC as a completion key, I would prefer having SPC self-insert, if it would also mean keeping the completion keys the same for file names and other names. This change means one more keymap for programmers to bind to, if they change or add minibuffer bindings, and (more importantly) it creates an inconsistency in user behavior. One argument that David R. made for having SPC self-insert was a blanket argument for consistency. I countered that the minibuffer is already a special kind of buffer. I argued that "it is important to try to remain consistent _within_ a given context (mode etc.); it is less important to impose consistency across all contexts". This change introduces inconsistency within the same context: minibuffer completion. If the argument is to not have the minibuffer be so special, well, this makes it even more special: _sometimes_ it is special. I understand (I imagine) the reason for not changing SPC except for file names - it's the same argument I made in general against changing SPC: the large spacebar is a handy key for completing. I'm guessing too (no reason was given, I believe) that the reason for having two distinct behaviors is that SPC is used more often in file names than in other names. IOW, this is a compromise, which recognizes the advantages and disadvantages of each approach, and tries to DTRT. It's true that function names and variable names are normally spaceless, but that's not true for buffer names, menu items, or names in general. Completion is about completing input by matching it against _strings_ (including symbol names). The completion mechanism is perfectly general, and it could be argued that it should treat all strings equally. That is, all printable chars should be self-insertable. I argued this for `?' previously, but that was rejected. Although I argued previously for keeping SPC for completion, I changed my mind (and my icicles.el library), based on the change to self-insert that I thought Emacs was making. As a result, I've been using SPC as self-insert for some time now, and I admit that it has taken some getting used to - I still occasionally try to use SPC to complete a command name. But I'm happy with the change - all printable chars self-insert. (The TAB key, as is usual in Emacs, is an exception.) I'm not happy, however, with a change that imposes a new minibuffer-completion map on programmers and two distinct minibuffer behaviors for SPC on users. Could this decision please be reconsidered?