From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Wed, 27 Jul 2011 23:27:11 +0300 Organization: JURTA Message-ID: <87sjpsnerd.fsf@mail.jurta.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311811532 19051 80.91.229.12 (28 Jul 2011 00:05:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2011 00:05:32 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 28 02:05: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 1QmE6R-00071z-Jh for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2011 02:05:27 +0200 Original-Received: from localhost ([::1]:54714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmE6Q-0006dZ-Fy for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 20:05:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmE6O-0006dH-0V for emacs-devel@gnu.org; Wed, 27 Jul 2011 20:05:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmE6M-0003Fx-R5 for emacs-devel@gnu.org; Wed, 27 Jul 2011 20:05:23 -0400 Original-Received: from smarty.dreamhost.com ([208.113.175.8]:45032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmE6M-0003FQ-Ir for emacs-devel@gnu.org; Wed, 27 Jul 2011 20:05:22 -0400 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id B46476E8061; Wed, 27 Jul 2011 17:05:20 -0700 (PDT) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 81F45451C363; Wed, 27 Jul 2011 17:05:19 -0700 (PDT) In-Reply-To: <87r55cjvef.fsf@stupidchicken.com> (Chong Yidong's message of "Tue, 26 Jul 2011 22:43:20 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.113.175.8 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:142411 Archived-At: > (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. In defface specs parameters like `min-width 10' are specified in the condition part of `defface' like `min-colors 88' as a list. For non-conditional parameters I agree that the plist syntax is better. And defface spec merges plist attributes from inherited faces. I also want to note that tags like `reuse-window' and `pop-up-window' are redundant in plists. Their meaning can be expressed as plists like `:window same', `:window other', `:buffer same'. This would bring them closer to the syntax of defface specs that is proven to be flexible and easy to configure. > If so, it might be good to revert everything and postphone > these changes to 24.2. It would be very sad to revert and move development backward.