From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Pretest begins end-June Date: Thu, 02 Jun 2011 10:27:56 +0200 Message-ID: <4DE7498C.8020109@gmx.at> References: <87y61ojhp4.fsf@stupidchicken.com> <4DE60326.8040505@gmx.at> <4DE64788.5060304@gmx.at> <3C10A4C0B92742BFA7EABDC8F7C0481C@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1307003352 12593 80.91.229.12 (2 Jun 2011 08:29:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 08:29:12 +0000 (UTC) Cc: 'Chong Yidong' , 'Stefan Monnier' , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 02 10:29:06 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QS3H6-0003Hd-07 for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 10:29:04 +0200 Original-Received: from localhost ([::1]:45437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS3H4-00036v-D1 for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 04:29:02 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS3G9-0002xZ-D1 for emacs-devel@gnu.org; Thu, 02 Jun 2011 04:28:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QS3G7-0003OQ-3L for emacs-devel@gnu.org; Thu, 02 Jun 2011 04:28:05 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:38472) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QS3G6-0003No-0t for emacs-devel@gnu.org; Thu, 02 Jun 2011 04:28:02 -0400 Original-Received: (qmail invoked by alias); 02 Jun 2011 08:27:58 -0000 Original-Received: from 62-47-63-183.adsl.highway.telekom.at (EHLO [62.47.63.183]) [62.47.63.183] by mail.gmx.net (mp032) with SMTP; 02 Jun 2011 10:27:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/lU3dbRXHlf59qezjuzIEFXw/5Lt6irBQnIvJi83 8FG9hUYzmgvsxN User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <3C10A4C0B92742BFA7EABDC8F7C0481C@us.oracle.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 213.165.64.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140051 Archived-At: > Which means that an app that calls another function that does (pop-to-buffer > buffer) cannot control the behavior. Intentionally so. Nested within that call there may be other `display-buffer' calls of which the caller is not aware. These calls should not be affected by any bindings. I do not have the slightest sentiment for my `pop-up-frames' nil `debug-on-error' t setting have (let ((pop-up-frames t)) (error "???")) pop up a new frame. > `pop-up-frames' is designed to be used as a dynamic ("special") var. Dynamic > binding can be very useful, as I'm sure you know. The change you describe works > against that usefulness. I suppose that `pop-up-frames' was designed as an option for the user to control the behavior of buffer display functions. The history of this and all related options is that of building a tower as follows: - Initially the user was provided the option `pop-up-frames' to control the creation of new frames. - Applications stole the customizations by let-binding this variable to whatever they considered appropriate. - The user was given back the option via `special-display-popup-frame'. - Applications stole the customizations again by binding `special-display-buffer-names' and `special-display-regexps' to nil. So where would you go from here? >> I changed most of the trivial calls already but some are >> rather special. > > Are you talking about just changing calls to `pop-to-buffer' in the Emacs > sources? Many, probably most, `pop-to-buffer' calls are out there in the wider > Emacs world, not just in the Emacs-Dev sources. That's why I raised this issue in my first mail. > More importantly, what you describe apparently limits the use and usefulness of > `pop-up-frames' (essentially eliminating it) - it's not just about existing > code. > > Please provide some way to dynamically bind _some_ var to control the behavior. > IOW, please restore the flexibility (control) you are apparently taking away. That flexibility has been given back to the user. martin