From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Sun, 31 Jul 2011 15:46:38 +0200 Message-ID: <4E355CBE.5050203@gmx.at> 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> <87vcumxury.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312120013 23873 80.91.229.12 (31 Jul 2011 13:46:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 13:46:53 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 15:46:49 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 1QnWLw-000660-HI for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 15:46:48 +0200 Original-Received: from localhost ([::1]:41147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnWLw-0002IF-5F for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 09:46:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnWLt-0002I7-1z for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:46:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnWLs-000499-2U for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:46:45 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:53851) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QnWLr-00048a-L9 for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:46:44 -0400 Original-Received: (qmail invoked by alias); 31 Jul 2011 13:46:39 -0000 Original-Received: from 62-47-53-199.adsl.highway.telekom.at (EHLO [62.47.53.199]) [62.47.53.199] by mail.gmx.net (mp009) with SMTP; 31 Jul 2011 15:46:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18doEEb6v4d7FOXVQO3bEMu1tHqFrSdgNZDa0tRbN JT5T6VwNcWL6LW User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87vcumxury.fsf@stupidchicken.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.23 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:142567 Archived-At: > One difference is that frame parameters don't interact with one another. > Each entry in default-frame-alist overrides any corresponding entry in > initial-frame-alist, and is overridden in turn by any corresponding > entry in window-system-default-frame-alist. With Emacs 23 `pop-up-frame-alist' overrides `default-frame-alist' and `special-display-frame-alist' overrides `pop-up-frame-alist', hence you may have to know the values of five lists to know what really goes on when popping up frames (disregarding `frame-inherited-parameters' which are applied after the frame has been created). These parameters interact like the specifiers of `display-buffer-alist' with one fundamental difference: The normalization procedure for frame parameters removes all instances of overriden parameters. It can do so because frame creation is guaranteed to succeed in the first attempt or fail forever. The normalization procedure for `display-buffer-alist' doesn't remove instances of overridden parameters because processing one method specifier may fail in which case the next method specifier has to be tried. > Another difference is that in default-frame-alist, each stored value > (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a > value of a frame parameter. In display-buffer-alist, each stored value > is a _list_ of specifiers, and each specifier has its own no-obvious > meaning. For example, in the specifier > > (reuse-window nil nil nil) > > each of the `nil's means something different, and you have to look up to > docstring to figure out what it is. That's true. Just as I never got around remembering the order of edges returned by `window-edges'. martin