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: Thu, 28 Jul 2011 12:41:05 -0400 Message-ID: <87r55axsri.fsf@stupidchicken.com> 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> <87sjpsnerd.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311871282 990 80.91.229.12 (28 Jul 2011 16:41:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2011 16:41:22 +0000 (UTC) Cc: martin rudalics , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 28 18:41:17 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 1QmTe9-0003d9-2m for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2011 18:41:17 +0200 Original-Received: from localhost ([::1]:40301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmTe8-0003vN-Dp for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2011 12:41:16 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmTe3-0003vA-75 for emacs-devel@gnu.org; Thu, 28 Jul 2011 12:41:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmTe1-0000Aq-JH for emacs-devel@gnu.org; Thu, 28 Jul 2011 12:41:11 -0400 Original-Received: from vm-emlprdomr-06.its.yale.edu ([130.132.50.147]:53437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmTe1-0000Al-G9 for emacs-devel@gnu.org; Thu, 28 Jul 2011 12:41:09 -0400 Original-Received: from furball ([128.36.14.95]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id p6SGf6Xg003229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 12:41:06 -0400 In-Reply-To: <87sjpsnerd.fsf@mail.jurta.org> (Juri Linkov's message of "Wed, 27 Jul 2011 23:27:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.147 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:142454 Archived-At: Juri Linkov writes: >> (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 don't know why the condition part of defface specs doesn't use a plist, and always figured it was a historical accident. But you raise a good point---the defface analogy helps clarify how to think about buffer display specs. Let's see where this analogy leads. Currently, `display-buffer-alist' stores lists of specifiers. Each specifier can specify either (1) A set of conditions, e.g. "display by reusing an existing window" and "the window must be already showing the buffer". or (2) "Extra" properties, like (pop-up-frame-function . foo) or (reuse-window-even-sizes . t). If (1) is analogous to the display type in a defface spec and (2) is analogous to face properties, then instead of lumping (1) and (2) into a single list, a specifier should have a form like (CONDITIONS ATTRIBUTES) e.g. something like (((method reuse-window) (buffer same) (window other)) (:even-sizes t :reuse-dedicated t)) or maybe ((:method reuse-window :buffer same :window other) (:even-sizes t :reuse-dedicated t)) Then, "merging" `display-buffer-alist' into the `display-buffer' specifier arg means combining the attributes for specifiers with the "same" conditional. But what does "the same conditional" mean? In the current design, a (reuse-window-dedicated . t) appearing in `display-buffer-alist' affects ALL instances of `reuse-window' specifiers in the specifier list. (Or something like that---AFAICT it affects all except those after another `reuse-window-dedicated' cons cell. This is one of the things that bugs me about the design.) So, should "the same conditional" mean `equal'? Then it will no longer be possible to use a single display-buffer-alist to affect ALL `reuse-window' conditional specs passed to `display-buffer'. I am personally fine with that.