From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Wed, 27 Jul 2011 00:59:28 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <4E2A7EBD.7050300@gmx.at> <87livooqt6.fsf@stupidchicken.com> <4E2B158B.1080101@gmx.at> <87wrf8iyse.fsf@stupidchicken.com> <4E2BEED2.5040608@gmx.at> <8739hvu6lh.fsf@stupidchicken.com> <4E2C50E6.3020103@gmx.at> <878vrnweju.fsf@stupidchicken.com> <4E2D34D7.4040002@gmx.at> <87r55cjvef.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1311742781 21053 80.91.229.12 (27 Jul 2011 04:59:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2011 04:59:41 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 27 06:59:33 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 1QlwDV-0002lH-AV for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 06:59:33 +0200 Original-Received: from localhost ([::1]:57114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlwDU-0004mA-PR for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 00:59:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlwDS-0004m5-Gi for emacs-devel@gnu.org; Wed, 27 Jul 2011 00:59:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlwDQ-000244-PN for emacs-devel@gnu.org; Wed, 27 Jul 2011 00:59:30 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:36729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlwDQ-000240-Mc for emacs-devel@gnu.org; Wed, 27 Jul 2011 00:59:28 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QlwDQ-0000MO-9x; Wed, 27 Jul 2011 00:59:28 -0400 In-reply-to: <87r55cjvef.fsf@stupidchicken.com> (message from Chong Yidong on Tue, 26 Jul 2011 22:43:20 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:142339 Archived-At: > From: Chong Yidong > Date: Tue, 26 Jul 2011 22:43:20 -0400 > Cc: emacs-devel@gnu.org > > (display-buffer buf > '((reuse-window :buffer same :window other) > (pop-up-window :root lru :side right :min-width 10))) > > This syntax is (IMO) much more readable. It is easy to guess what every > element means---one problem I have with the current design is that I > have to delve into the docstring to work out what the different elements > and special tags mean. And it has the advantage of similarity with > other facilities in Emacs, like defface specs. OTOH, we have the example of frame parameters alist, which supports merging with the default-frame-alist, is quite self-explanatory, and works quite well in practice, AFAIK. So why wouldn't display-buffer-alist be useful as an alist as well, without any need for a plist? > My inclination would be to keep the display specifier argument to > `display-buffer', switching to the plist syntax, but leave out > `display-buffer-alist' until we can work out a better way to do merging > (e.g. in 24.2). If there's no display-buffer-alist, then how can users customize the behavior to their liking? The current code sets up display-buffer-alist from various user options for backward compatibility; leave display-buffer-alist out, and those options will have no effect on behavior whatsoever, IIUC. > If so, it might be good to revert everything and postphone these > changes to 24.2. Alternatively, we could postpone the pretest and invest the time into this issue now. IMO, reverting everything, or even a large portion of it, would be extremely unkind to Martin's efforts, especially that the only reason for that is our self-imposed date of pretest start. That date is by no means sacred. We should cherish significant contributions like this one much more than we cherish the schedule of Emacs releases.