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: display-buffer-alist simplifications Date: Wed, 31 Aug 2011 06:33:48 -0700 Message-ID: <59CE5DD60A8D4C529BD3DC23524FB52B@us.oracle.com> References: <87mxgem09k.fsf@stupidchicken.com><871ux2nsrw.fsf@stupidchicken.com> <4E3AA5DA.8030403@gmx.at><87mxfnn414.fsf@stupidchicken.com> <4E3D41F2.8060801@gmx.at> <4E3FA812.3080009@gmx.at><87zkjkb572.fsf@mail.jurta.org> <4E3FD5ED.5000206@gmx.at> <4E412E2D.90908@gmx.at> <4E422ECA.2020207@gmx.at> <4E43A253.9040404@gmx.at> <4E59F6D1.5060800@gmx.at> <4E5BE2B9.9030307@gmx.at><87zkiqicdo.fsf@stupidchicken.com> <87hb4ythby.fsf@stupidchicken.com> 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 1314798908 980 80.91.229.12 (31 Aug 2011 13:55:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 31 Aug 2011 13:55:08 +0000 (UTC) Cc: 'Juri Linkov' , 'martin rudalics' , 'Stefan Monnier' , emacs-devel@gnu.org To: "'Chong Yidong'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 31 15:55:00 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 1QylFo-0005gq-Iw for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2011 15:54:56 +0200 Original-Received: from localhost ([::1]:36298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QylFo-0002DA-5C for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2011 09:54:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QylFl-0002BX-95 for emacs-devel@gnu.org; Wed, 31 Aug 2011 09:54:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QylFk-00067X-4P for emacs-devel@gnu.org; Wed, 31 Aug 2011 09:54:53 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:38448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QylFj-00067P-SO for emacs-devel@gnu.org; Wed, 31 Aug 2011 09:54:52 -0400 Original-Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7VDsQEq008095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 Aug 2011 13:54:28 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 p7VDnqXq026076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Aug 2011 13:54:25 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7VDXno9007212; Wed, 31 Aug 2011 08:33:49 -0500 Original-Received: from dradamslap1 (/10.159.58.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Aug 2011 06:33:48 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87hb4ythby.fsf@stupidchicken.com> Thread-Index: AcxnikqACqpqBYpDSCGqN3v0GMSbMwAVlOgw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020201.4E5E3D27.0087,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 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:143660 Archived-At: > > I say take the time to get it right. What's the rush? > > Conversely, as long as the Emacs 23 variables continues to > work, we have all the time in the world to introduce the full > set of new window management features. Precisely. So do not include them in Emacs 24.1. Or include them with a giant caveat that they are experimental and user code should not depend on them. IOW, you might want people to play with this, to get some feedback. But you shouldn't want people to use it seriously and come to expect it to continue as is. Play if you want, but do not work with this. Things that are not fully baked are typically made available in some backdoor manner (e.g. under a flag/event that users must set, after signing in blood that they understand that this is not supported). > The hold-up is fine for now, because meanwhile other bugs are getting > fixed and the manuals are getting updated. But the timeline is not > infinitely elastic--- Why not? What real deadline does free software development have? There might be practical limits such as the lost opportunity of someone not being available to help after some date, but it's not like you have to deal with contracts and paying customers. Let's not exaggerate. You can do anything you want wrt development schedules. > the whole point of a feature freeze is that new > features are supposed to be ready for testing/integration at more or > less the same time, instead of waiting on one another. Which is why features that are not ready get pulled from a release. But the timing of releases is typically based on concerns and constraints (e.g. commercial) that Emacs is for the most part not burdened with. > Another reason I would prefer to reduce the initial set > of changes to the minimum working set of "base" code Hey, if that's the case, then either (a) this feature doesn't belong in 24.1 - save it altogether for 24.2 or (b) 24.1 should wait until this feature is 100% ready. And I thought there had already been a decision to do (b). > is to get that code into the repository sooner rather > than later. In that case your choice is apparently (a) - not include this feature that is not fully baked in 24.1.