From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Pretest? Date: Wed, 14 Mar 2007 11:07:26 +0100 Message-ID: <86k5xkw335.fsf@lola.quinscape.zz> References: <87slcf8qxr.fsf@stupidchicken.com> <20070309135920.GA3560@kobe.laptop> <87hcsuwk6w.fsf@stupidchicken.com> <86slc8w4or.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1173866935 14459 80.91.229.12 (14 Mar 2007 10:08:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2007 10:08:55 +0000 (UTC) Cc: cyd@stupidchicken.com, rms@gnu.org, emacs-devel@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 14 11:08:49 2007 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 1HRQPW-0004IQ-KC for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2007 11:08:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRQQO-0004Ds-DQ for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2007 05:09:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HRQPA-0003mK-Nw for emacs-devel@gnu.org; Wed, 14 Mar 2007 06:08:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HRQP9-0003lc-0c for emacs-devel@gnu.org; Wed, 14 Mar 2007 06:08:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HRQP8-0003lX-SW for emacs-devel@gnu.org; Wed, 14 Mar 2007 05:08:22 -0500 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HRQOG-0000fe-3C for emacs-devel@gnu.org; Wed, 14 Mar 2007 06:07:28 -0400 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id LAA13860 for ; Wed, 14 Mar 2007 11:07:24 +0100 X-Delivered-To: Original-Received: (qmail 9570 invoked from network); 14 Mar 2007 10:07:26 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 14 Mar 2007 10:07:26 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 454C3C1BA2; Wed, 14 Mar 2007 11:07:26 +0100 (CET) In-Reply-To: (Juanma Barranquero's message of "Wed\, 14 Mar 2007 10\:44\:15 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-detected-kernel: 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:67915 Archived-At: "Juanma Barranquero" writes: > On 3/14/07, David Kastrup wrote: > >> However, we should still come up with a suitable strategy >> concerning what we should do when we are in a minibuffer for other >> reasons (such as M-x). > > [...] > >> With enable-recursive-minibuffers to t, however, would then cause the >> message "Cannot switch buffers in minibuffer window". > > Curious. I have enable-recursive-minibuffers set to t, but I would > still expect emacsclient to interrupt M-x, etc. What is "curious" about that? I proposed what I consider a pretty logical and consistent way of dealing with emacsclient calls, and then mentioned a drawback of this for a certain setting. And now you call it curious that what I mention as a drawback does not strike you as the best behavior? Curious. Anyway: people are ready to forward their expectations all around. The question is how we can tie the various expectations into some rules and behavior that will be acceptable to most people under most settings. If we can find a simple rule set working for all cases reasonably well, this would be optimal. I proposed a simple rule set and mentioned that I considered some special case of it undesirable. Can you can come up with a good rule set (with as few exceptions as possible, since we want to avoid introducing lots of special cases) that is better-behaved? If so, please do. -- David Kastrup