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: Pretest begins end-June Date: Wed, 1 Jun 2011 08:21:25 -0700 Message-ID: <3C10A4C0B92742BFA7EABDC8F7C0481C@us.oracle.com> References: <87y61ojhp4.fsf@stupidchicken.com> <4DE60326.8040505@gmx.at> <4DE64788.5060304@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1306978195 29053 80.91.229.12 (2 Jun 2011 01:29:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 01:29:55 +0000 (UTC) Cc: 'Chong Yidong' , emacs-devel@gnu.org To: "'martin rudalics'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 02 03:29:51 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 1QRwjL-0003qW-Sp for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 03:29:48 +0200 Original-Received: from localhost ([::1]:55882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRwjL-0003O0-1e for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2011 21:29:47 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRvaH-0001Fx-39 for emacs-devel@gnu.org; Wed, 01 Jun 2011 20:16:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRvaF-00013G-9W for emacs-devel@gnu.org; Wed, 01 Jun 2011 20:16:20 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:52561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRnF8-0001Ra-Iz for emacs-devel@gnu.org; Wed, 01 Jun 2011 11:21:58 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p51FLp0L032615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 15:21:53 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p51FLnRH028305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 15:21:50 GMT Original-Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p51FLhNA008094; Wed, 1 Jun 2011 10:21:43 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Jun 2011 08:21:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4DE64788.5060304@gmx.at> Thread-Index: AcwgZiGjb2ycHeP8SqSoWuU8aODiYQABm5Yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090203.4DE65911.00D4:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 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:140042 Archived-At: > Hence, if an application now wants to pop up a buffer in > another frame it must do something like > (pop-to-buffer buffer-or-name 'other-frame) > instead of (let ((pop-up-frames t)) (pop-to-buffer buffer)) Which means that an app that calls another function that does (pop-to-buffer buffer) cannot control the behavior. What you describe is no big deal for code that calls `pop-to-buffer' directly. But it makes it difficult if not impossible to control the behavior when code calls other code that in turn calls `pop-to-buffer'. Without access to changing the latter code, one's goose is pretty much cooked. `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 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. 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.