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: Tue, 30 Aug 2011 00:10:30 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <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> <4E412E2D.90908@gmx.at> <4E422ECA.2020207@gmx.at> <4E43A253.9040404@gmx.at> <4E59F6D1.5060800@gmx.at> <4E5BE2B9.9030307@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1314677450 21097 80.91.229.12 (30 Aug 2011 04:10:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2011 04:10:50 +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 Tue Aug 30 06:10:44 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 1QyFes-0004VV-Vq for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2011 06:10:43 +0200 Original-Received: from localhost ([::1]:46280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyFer-0008TD-TA for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2011 00:10:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:32920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyFep-0008T8-1e for emacs-devel@gnu.org; Tue, 30 Aug 2011 00:10:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyFen-0005C2-SQ for emacs-devel@gnu.org; Tue, 30 Aug 2011 00:10:38 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:8604 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyFen-0005By-Nu for emacs-devel@gnu.org; Tue, 30 Aug 2011 00:10:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPthXE64rwMJ/2dsb2JhbABCqAZ4gUABAQQBViMFCws0EhQYDSSIBbgGhk0EoAiEPA X-IronPort-AV: E=Sophos;i="4.68,300,1312171200"; d="scan'208";a="133463184" Original-Received: from 184-175-3-9.dsl.teksavvy.com (HELO ceviche.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 30 Aug 2011 00:10:36 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id C933A660B6; Tue, 30 Aug 2011 00:10:30 -0400 (EDT) In-Reply-To: <4E5BE2B9.9030307@gmx.at> (martin rudalics's message of "Mon, 29 Aug 2011 21:04:25 +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:143644 Archived-At: >> Until now there is no caller out there that specifies "I want to reuse >> an existing window and I want it to be the LRU", and neither is there >> a user out there that has a config that says "buffers names TOTO should >> be displayed in an existing window and should use the largest window". >> So it's not a real problem. > So when we write a function `display-buffer-near-minibuffer' and want to > reuse the bottom-most window we can't decompose? I don't know what you mean by "decompose". I suspect you're referring to the way your current display-buffer-alist provides very fine-grained building blocks that are combined in display-buffer-alist specifiers. If so, indeed, my design does not make such decomposition easy. But I don't think it's a problem: the decomposition can be done in the Elisp code instead (i.e. display-buffer-near-minibuffer can call some display-buffer-reuse-foo function). >> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window, >> other-window, other-frame, dedicated-or-not, existing-window) so as to >> be able to mark the various old config vars as obsolete. > Without offering anything people can customize instead but a single > option called `display-buffer-alist' to choose one of these functions? Almost. Actually, I think there are 2 defcustoms: display-buffer-alist and display-buffer-default-rule. The default-rule will replace things like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while display-buffer-alist will replace things like same-window-* and special-display-*. Juri writes: > Or with Stefan's design without decomposition > these actions could be specified as: > '(display-buffer-reuse-lru-window . ()) > '(display-buffer-reuse-largest-window . ()) No, since all these params belong to display-buffer-alist, the "display-buffer-" prefix would be unnecessary. Stefan