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: Wed, 01 Jun 2011 21:07:58 +0200 Message-ID: <4DE68E0E.5030909@gmx.at> References: <87y61ojhp4.fsf@stupidchicken.com> <4DE60326.8040505@gmx.at> <4DE64788.5060304@gmx.at> <4DE661A8.7010706@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1306955312 1749 80.91.229.12 (1 Jun 2011 19:08:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 1 Jun 2011 19:08:32 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 01 21:08:28 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 1QRqmJ-0007ko-OZ for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2011 21:08:27 +0200 Original-Received: from localhost ([::1]:36362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqmH-0002AM-IF for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2011 15:08:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRqlw-00029d-Ba for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRqlv-0003Nd-B6 for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:04 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:44564) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QRqlu-0003N9-O5 for emacs-devel@gnu.org; Wed, 01 Jun 2011 15:08:03 -0400 Original-Received: (qmail invoked by alias); 01 Jun 2011 19:08:00 -0000 Original-Received: from 62-47-57-149.adsl.highway.telekom.at (EHLO [62.47.57.149]) [62.47.57.149] by mail.gmx.net (mp041) with SMTP; 01 Jun 2011 21:08:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18qBTwtL1kqaVpch+8QCDaJ/5B4jcIQi6Zh9CnaRG j+nQ114KKGM53t User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.23 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:140031 Archived-At: > Let me put the question differently: > *how* can we support code that rebinds pop-up-frames? It's a bit like having the cake and eating it too. > I think preserving backward compatibility for this case is important, > because it is used in many packages, not all of which are included in > Emacs. Agreed. > IIUC, the problems are: > 1- detect that pop-up-frames was set. > 2- decide whether pop-up-frames was set by user or let-bound by the caller. > 3- for each of those two cases, take this request into account. > 4- same for pop-up-windows. > > Case 1 is easy (set the default value to `unset' and you're done). I'm not 100% sure whether this could lead to difficulties (IIUC I would have to hardcode the Emacs 23 default values of `split-height-threshold' and `pop-up-windows' in `display-buffer') but let's agree. > Case 2 is more difficult. Of course, we could add a new primitive that > walks the specpdl stack to decide if a var is let-bound or not, but that > doesn't sound very appealing. Not really. > Case 3 doesn't sound too hard; IIUC it involves losing some > functionality but that functionality is absent from Emacs-23 anyway. > Do we really need to solve case 2? Probably not. Suppose a user has set `split-height-threshold' to some value for use in Emacs 23 and in Emacs 24 wants to use a new functionality of `display-buffer-alist' say apply `fit-window-to-buffer' for adjusting the window height. What shall `display-buffer' do? Respect the value of `split-height-threshold'? Adjust the height of the window? Do both? > If we declare pop-up-frames and pop-up-windows as obsolete, I think it's > OK to have an heuristic simulation of its semantics as long as it > handles the known cases well enough. I think I won't have great problems providing an acceptable heuristic for `pop-up-frames'. But I'm afraid that packages outside Emacs have some very unknown cases in store for me. martin