From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: menu-bar: disable items when no frame visible Date: Sun, 25 Dec 2005 10:54:07 +0100 Message-ID: <574B84E7-DF6B-4220-BE7E-9AE69AFF135D@gmail.com> References: <708F3D2D-A87C-4F80-BC27-171D82653F4D@gmail.com> <069BF3EB-C5E4-4042-91E9-0DFB37C58E99@gmail.com> <87u0d3cu9y.fsf@jurta.org> <87y82b7evb.fsf@jurta.org> <9F80EEEC-3EDF-47B5-9837-2091650A8C5D@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1135506658 7868 80.91.229.2 (25 Dec 2005 10:30:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 25 Dec 2005 10:30:58 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 25 11:30:56 2005 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 1EqT9T-0004yH-1V for ged-emacs-devel@m.gmane.org; Sun, 25 Dec 2005 11:30:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EqT8x-0007l6-Ad for ged-emacs-devel@m.gmane.org; Sun, 25 Dec 2005 05:30:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EqT1T-00079h-Lu for emacs-devel@gnu.org; Sun, 25 Dec 2005 05:22:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EqT1E-000793-Lu for emacs-devel@gnu.org; Sun, 25 Dec 2005 05:22:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EqT18-00078o-9e for emacs-devel@gnu.org; Sun, 25 Dec 2005 05:22:20 -0500 Original-Received: from [66.249.92.200] (helo=uproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EqT0k-0001ff-PX for emacs-devel@gnu.org; Sun, 25 Dec 2005 05:21:55 -0500 Original-Received: by uproxy.gmail.com with SMTP id u2so313317uge for ; Sun, 25 Dec 2005 02:21:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=ojq/NdBlJpK52zUN3p7p0VmmS9Pm2/0EYJILAcmIZQcZzwO1b/tJLCMBK+dlARWyCDyp/5yzKSFW8PkF+RHPo91bACPgXkraWtvuJ3F/XihkEUUNbBm6MmtpVo7OZv5BiXlzS+idot+Gfh9SETK1I7bjMLbzC4ZMedt3l1cz45k= Original-Received: by 10.67.27.1 with SMTP id e1mr1539581ugj; Sun, 25 Dec 2005 02:21:03 -0800 (PST) Original-Received: from ?217.247.135.242? ( [217.247.135.242]) by mx.gmail.com with ESMTP id q1sm2664639uge.2005.12.25.02.20.55; Sun, 25 Dec 2005 02:21:02 -0800 (PST) In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.746.2) 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:48349 Archived-At: On 25 Dec 2005, at 03:51, Richard M. Stallman wrote: > But I would suggest improving find-file to catch the error in > switch- > to-buffer and show the buffer in another window in that case, at > least when called interactively. > > Why do you find it so often useful to invoke Find File > while you're in a minibuffer? Usually I have started something else which reads an argument in the minibuffer, either in error or because I'd like to look up something in another file in order to supply the right input. This applies to invoking switch-to-buffer with the same reasoning -- you'd like to look up something else. WIthout having counted these cases, I'd say the majority of cases is erroneous invoking of the first command that gets me to the minibuffer. (Of course, I should do C-g, but that doesn't happen.) That's why I've been looking for a way to enable "sequential" instead of "recursive" minibuffers (see my recent message below). Either method (switch-to-buffer using a different window if in minibuffer and interactive, and: sequential minibuffers) address similar situations and would be of benefit at least to the inexperienced user. Begin forwarded message: From: david.reitter@gmail.com Subject: Sequential instead of recursive minibuffers? Date: 15 December 2005 20:02:28 GMT+01:00 To: Help-gnu-emacs@gnu.org Is it possible to automatically signal a `quit' to the current minibuffer prompt function when another minibuffer is set up? We've had a discussion back in summer: http://lists.gnu.org/archive/html/help-gnu-emacs/2005-07/msg00021.html To explain this a little further: I can currently choose between normal (simple) minibuffers and recursive minibuffers. The difference is in the behavior if a user presses a key sequence bound to an interactive command, sees the prompt and decides that it was the wrong command. Now (without a C-g in between) he remembers the correct command and enters that one. The first option will always signal an error ("Command attempted to use minibuffer while in minibuffer"), which is somewhat confusing and certainly annoying to me. A couple of months ago, when I didn't know anything about this minibuffer business, I was confused big time! The "recursive minibuffer" setting will do just what it says - which means that the old prompt will reappear as soon as the new command is finished. This is equally confusing, in particular to new users. I often get caught in situations where several minibuffers stack up and I have to C-g several times to get out of the situation. In the previously mentioned discussion, some UI-based workarounds have been proposed (e.g. different colors depending on minibuffer state). What I'd like to configure in my Emacs is a sequential minibuffer: As soon as I enter another interactive command, the currently running one is quit. My first attempt at doing that was (setq enable-recursive-minibuffers nil) (add-hook 'minibuffer-setup-hook 'keyboard-quit) which fails because `keyboard-quit' is, of course, executed in the wrong context. Again, the logic could be: - if we're in an interactive command (call-interactively) that uses the minibuffer (A) - and another interactive is called (but not via a minibuffer- specific keymap) which prompts for some input in the minibuffer (B) then signal 'quit' to A and continue with B. That way I can do M-x M-x ...., or something like C-x C-f di C-h f ding RET (where I confused C-h f with C-x C-f) without any error messages, without remaining minibuffers that I don't want and with exactly the desired result. I have no idea how to accomplish this -- any suggestions would be appreciated.