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: Mon, 01 Aug 2011 20:57:23 +0200 Message-ID: <4E36F713.8090209@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> <87mxg2fw74.fsf@mail.jurta.org> <4E355D5A.30409@gmx.at> <87oc09zg85.fsf@mail.jurta.org> 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 1312225057 21960 80.91.229.12 (1 Aug 2011 18:57:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2011 18:57:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 01 20:57:32 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 1QnxgB-00059q-Nj for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2011 20:57:31 +0200 Original-Received: from localhost ([::1]:34499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnxgB-0005mt-Cg for ged-emacs-devel@m.gmane.org; Mon, 01 Aug 2011 14:57:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnxg8-0005gu-Iw for emacs-devel@gnu.org; Mon, 01 Aug 2011 14:57:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnxg7-000166-Bj for emacs-devel@gnu.org; Mon, 01 Aug 2011 14:57:28 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:42391) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qnxg6-00015o-Tv for emacs-devel@gnu.org; Mon, 01 Aug 2011 14:57:27 -0400 Original-Received: (qmail invoked by alias); 01 Aug 2011 18:57:25 -0000 Original-Received: from 62-47-55-42.adsl.highway.telekom.at (EHLO [62.47.55.42]) [62.47.55.42] by mail.gmx.net (mp057) with SMTP; 01 Aug 2011 20:57:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+VUtk+uEWVdvQvQnsNjL1DupKf5BJiHHesO0fWyJ Ie5UmwCmDzvwle User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87oc09zg85.fsf@mail.jurta.org> 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:142640 Archived-At: > I meant "user-specific behavior can override the _default_ and > function-specific behavior", i.e. I forgot to mention that > users can override the default behavior as well. If now the default > behavior is based on the users old settings, then users new settings > should override them. For instance, when old customization in .emacs > sets `pop-up-frames' to t, and the user customizes `display-buffer-alist' > to not create a frame, then settings from `display-buffer-alist' > should override the old settings `pop-up-frames'. That's what the current code does, hopefully. > My concern is how users will be able to override parts of the > default behavior? For instance, how users can specify a rule > to override the default and to not to balance/even window sizes? > I understand that using settings like (reuse-window-even-sizes . nil) > and (reuse-window-even-sizes . t). Yes. > How easy is to add new macros like `near-minibuffer' and `below-selected'? > Can users add own macros? Currently there's only the constant `display-buffer-macro-specifiers'. I made it a constant because I considered modifying it unsafe. We could make it customizable. > I'm sure that most authors will be lazy or forget to add labels. > And how users are supposed to deal with the lack of labels? > Should they send mails to the authors asking them to add labels? > Honestly, I think adding labels was good intention but they are useless. Maybe. I have no strong opinion. > For some exceptional cases where it's impossible to override the > function-specific behavior based on `buffer-or-name' or `this-command', > then a label could be specified as part of specifiers like > `((label . "info-other-window") ...)'. > > Or maybe we can't remove the 3rd argument of `display-buffer' > for backward-compatibility with the old version that had 3 arguments, > so we should keep the 3rd argument and use it for something? That was part of the idea of the labels concept. martin