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: Usability suggestion : completion for M-: Date: Sun, 16 Mar 2008 09:49:44 -0700 Message-ID: <000701c88785$bd26dce0$0600a8c0@us.oracle.com> References: <87ejaei4iz.fsf@stupidchicken.com> <87hcf7r7vl.fsf@jurta.org> <003001c886f5$366f4330$0600a8c0@us.oracle.com> <874pb7ikt7.fsf@jurta.org> <000501c8873d$4ff68550$0600a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205686392 18439 80.91.229.12 (16 Mar 2008 16:53:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2008 16:53:12 +0000 (UTC) Cc: 'Juri Linkov' , cyd@stupidchicken.com, emacs-devel@gnu.org To: "'paul r'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 16 17:53:40 2008 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 1Jaw76-00013b-VY for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 17:53:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jaw6X-0001u8-I5 for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2008 12:53:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jaw4z-0000cK-30 for emacs-devel@gnu.org; Sun, 16 Mar 2008 12:51:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jaw4x-0000as-85 for emacs-devel@gnu.org; Sun, 16 Mar 2008 12:51:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jaw4w-0000aS-PX for emacs-devel@gnu.org; Sun, 16 Mar 2008 12:51:22 -0400 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 1Jaw4w-0004oE-Ez for emacs-devel@gnu.org; Sun, 16 Mar 2008 12:51:22 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m2GGpI2v000393; Sun, 16 Mar 2008 10:51:18 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m2GGDd6E023054; Sun, 16 Mar 2008 10:51:17 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3614416701205686172; Sun, 16 Mar 2008 09:49:32 -0700 Original-Received: from dradamslap1 (/141.144.88.54) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Mar 2008 09:49:31 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciHVJBr3af1Z/ZhTACOdulAo3NXXAAJqrxw In-Reply-To: X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: 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:92753 Archived-At: > > Fine. Allow me to be the exception. We can do better. > > M-: can be better still. > > Agree, but in the meantime, binding TAB to tabulation character > instead of symbol completion in the current one-line minibuffer is > inconsistent with the behaviour of others minibuffer prompts. On the contrary. TAB in the minibuffer either (1) self-inserts (when not using completing-read or read-file-name) or (2) completes the entire minibuffer input in such a way that you can hit RET to enter the completed input. That's the case now for all minibuffer input. What you propose is inconsistent with that. You are proposing something new: (3) complete only part of the input, so that RET after TAB won't necessarily make sense. That's OK, _if_ there are mitigating reasons - blind, systematic consistency is not a goal in itself. But please recognize that the current TAB bindings are consistent, and your proposal breaks that consistency. Why do that, especially if, as you admit, it is just a temporary hack: "in the meantime"? In-the-meantime changes can become fixed by neglect, for no special reason, rather than being just temporary exceptions to the rule. The result of lots of such changes would be ad-hoc inconsistency throughout the UI. If the right thing to do is (as you apparently agree) to improve M-: so that it is more like Lisp modes, with TAB assuming its indenting role (or perhaps a hybrid indenting role), then we should not DTWT "in the meantime".