From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Tue, 30 Aug 2011 23:01:21 -0400 Message-ID: <87hb4ythby.fsf@stupidchicken.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1314759698 11049 80.91.229.12 (31 Aug 2011 03:01:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 31 Aug 2011 03:01:38 +0000 (UTC) Cc: 'Juri Linkov' , 'martin rudalics' , 'Stefan Monnier' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 31 05:01:30 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 1Qyb3R-00017s-4e for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2011 05:01:29 +0200 Original-Received: from localhost ([::1]:43405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qyb3Q-0000It-GH for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2011 23:01:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qyb3N-0000Ik-Hr for emacs-devel@gnu.org; Tue, 30 Aug 2011 23:01:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qyb3M-0007gV-DY for emacs-devel@gnu.org; Tue, 30 Aug 2011 23:01:25 -0400 Original-Received: from vm-emlprdomr-02.its.yale.edu ([130.132.50.143]:44267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qyb3M-0007gN-3f for emacs-devel@gnu.org; Tue, 30 Aug 2011 23:01:24 -0400 Original-Received: from furball (dhcp-128-36-14-41.central.yale.edu [128.36.14.41]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id p7V31LAn016216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Aug 2011 23:01:21 -0400 In-Reply-To: (Drew Adams's message of "Tue, 30 Aug 2011 19:07:20 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.143 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:143650 Archived-At: "Drew Adams" writes: >> now that we've settled on a workable design > > You/we have? I hadn't gotten that impression from scanning the > thread. I (think I) see new proposals and counter-proposals everyday. You haven't been reading the thread carefully, then. >> For example, I would not spend time on the defcustom definitions for >> display-buffer-alist and display-buffer-default-rule, if that proves >> complicated---you could just make them defvars for now. > > Huh? I thought the decision was that there was no hurry for Emacs 24 > and that you wanted to get this right first. Sounds like now someone > wants to go to market in a hurry. > > 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. 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---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. Another reason I would prefer to reduce the initial set of changes to the minimum working set of "base" code is to get that code into the repository sooner rather than later. Then other Emacs developers can help at working out integration issues, reducing the current bottleneck (i.e. "Martin doing everything").