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: feature request: indicator of minibuffer-recursion depth Date: Wed, 15 Mar 2006 11:52:59 -0800 Message-ID: References: <9734F5FD-FD8F-4889-893E-6EB3D90018E7@gmail.com> 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 1142452415 14847 80.91.229.2 (15 Mar 2006 19:53:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2006 19:53:35 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 20:53:30 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 1FJc3b-00018u-LZ for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 20:53:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJc3b-0007o2-8e for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 14:53:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FJc3N-0007jn-28 for emacs-devel@gnu.org; Wed, 15 Mar 2006 14:53:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FJc3M-0007hu-0O for emacs-devel@gnu.org; Wed, 15 Mar 2006 14:53:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJc3L-0007hX-Rf for emacs-devel@gnu.org; Wed, 15 Mar 2006 14:53:03 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FJc7q-0001pg-1u for emacs-devel@gnu.org; Wed, 15 Mar 2006 14:57:42 -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 k2FJr0ST025983 for ; Wed, 15 Mar 2006 13:53:01 -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 k2FJr0dS019201 for ; Wed, 15 Mar 2006 12:53:00 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2FJqxUp019184 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 15 Mar 2006 12:53:00 -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: <9734F5FD-FD8F-4889-893E-6EB3D90018E7@gmail.com> 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:51673 Archived-At: I remember well that C-g was one of the essential commands that I didn't learn early on, so the situation caused a lot of frustration. Not that this is a defense of `C-g' or anything else, but one thing I learned many moon ago is that perhaps the first thing to learn about something new is how to stop it, get out of it, quit it, or (if possible) undo it. ;-) `C-x C-c' and `C-g' should be emblazoned on the startup screen. [This goes for teaching, as well, BTW. And the second thing to teach is how to use or modify something (e.g. a program) that exists, not how to create a new one; it's nearly always simpler (and more rewarding to newbies, and more informative) to use or change something that exists than it is to create one from scratch.] So if you're seriously considering modifying the minibuffer interaction before the release, I was clear in my initial proposal to consider this feature - here is the first line of that message (emphasis added): For consideration ***after*** the release - I urge you to make the default setting (no recursion) easier to use. The message could be improved. When I see "Command attempted to use minibuffer while in minibuffer" my reaction is "Of course the command I'm using in the minibuffer attempts to use the minibuffer while in the minibuffer!" There are two problems understanding the message: 1) "Command" - what command? I might not be aware that I invoked a command. 2) "use the minibuffer" is not clear. This might be better: "`...' (command `...') cannot be run during minibuffer input", where the first `...' is whatever you typed that invoked a command, and the second `...' is the command name. For your example, the message would be: `C-x b' (command `switch-to-buffer') cannot be run during minibuffer input Additional info *might* be added to the message, and the command name might be dropped. Some additional info that could help: . Mention that the command cannot be run because it would, itself, ask for input . Mention that you can toggle `enable-recursive-minibuffers' to allow the command to be run. Another possibility for the message: You cannot use `C-x b' while entering input, because it too prompts for input One solution would be to automatically quit the command that's occupying the minibuffer whenever another command requires it (i.e. instead of signaling the above error). That might be confusing also. If you don't realize that what you type is bound to a command, then you think you are still inputting what the first command wants, and in fact the first command has already been (silently) offed.