From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Mon, 08 Aug 2011 14:51:53 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <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> <4E355D2C.40709@gmx.at> <87k4axzg7j.fsf@mail.jurta.org> <87oc092gy0.fsf@stupidchicken.com> <4E380897.5000406@gmx.at> <871ux2nsrw.fsf@stupidchicken.com> <4E3AA5DA.8030403@gmx.at> <87mxfnn414.fsf@stupidchicken.com> <4E3D41F2.8060801@gmx.at> <4E3FA812.3080009@gmx.at> <87zkjkb572.fsf@mail.jurta.org> <4E3FD5ED.5000206@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312829532 4963 80.91.229.12 (8 Aug 2011 18:52:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2011 18:52:12 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 20:52:05 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 1QqUvj-0008N0-9p for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 20:52:03 +0200 Original-Received: from localhost ([::1]:54553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqUvf-0000YM-Qr for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 14:51:59 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqUvd-0000UH-Ei for emacs-devel@gnu.org; Mon, 08 Aug 2011 14:51:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqUvc-0001AJ-0k for emacs-devel@gnu.org; Mon, 08 Aug 2011 14:51:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:32688 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqUvb-00019x-Qq for emacs-devel@gnu.org; Mon, 08 Aug 2011 14:51:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPgvQE5FxKeo/2dsb2JhbABDpyZ4gUABAQQBViMQCzQSFBgNJIgAvkWGRwSfVYQx X-IronPort-AV: E=Sophos;i="4.67,338,1309752000"; d="scan'208";a="130098315" Original-Received: from 69-196-167-168.dsl.teksavvy.com (HELO ceviche.home) ([69.196.167.168]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 08 Aug 2011 14:51:54 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 04E2E6610B; Mon, 8 Aug 2011 14:51:54 -0400 (EDT) In-Reply-To: <4E3FD5ED.5000206@gmx.at> (martin rudalics's message of "Mon, 08 Aug 2011 14:26:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:143026 Archived-At: >> We should keep the old mess in 2 for backward-compatibility >> and design a new clean and simply way to specify 3 and 4, so >> we don't need to merge new specifiers with old user settings in 2, >> because new specifiers just override the old user settings. > With the scheme sketched above users have no chance to specify what they > want when they want to use the new design _and_ respect the application > specifiers. When they set the new specifiers they would override the > application. Yes, and I think that's fine. We may want to provide a 5th level for elisp code that lets it override user settings. This could then be used for things like C-x 4 and C-x 5 which are ways for the user to say "please override my own settings". For the `not-this-window' behavior, I'm still not sure how best to do it. My current idea is to redefine RULEs from (FUNCTION . ARGS) to (FUNCTION . ALIST), and then FUNCTION called is the one from the highest precedence, and the ALIST passed to it is the concatenation of all the ALISTs (the one from display-buffer-default-rule, plus the one from the caller, plus the one from display-buffer-alist, plus the one from display-buffer-override-rule), and `not-this-window' would be one of the possible ALIST keys. So if it's provided by the caller it will appear as arg to FUNCTION, unless it's explicitly overridden by a (not-this-window . nil) element in the display-buffer-alist. >> Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg >> over the old settings in `same-window-regexps' etc.? IOW, when the >> `SPECIFIERS' arg is `other-window' then `display-buffer' should ignore >> the values of `same-window-regexps' etc. > Because this would change the behavior of `display-buffer' for users who > prefer good ol' `display-buffer'. It should only change the behavior for calls to display-buffer which use the new RULE/SPECIFIER parameter or for users who set display-buffer-alist. Stefan