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: Fri, 12 Aug 2011 22:29:23 -0400 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <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> <4E412E2D.90908@gmx.at> <4E422ECA.2020207@gmx.at> <4E43A253.9040404@gmx.at> <4E45330C.9060801@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1313202578 25812 80.91.229.12 (13 Aug 2011 02:29:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 13 Aug 2011 02:29:38 +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 Sat Aug 13 04:29:33 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 1Qs3yd-0004cZ-J8 for ged-emacs-devel@m.gmane.org; Sat, 13 Aug 2011 04:29:31 +0200 Original-Received: from localhost ([::1]:48974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qs3yc-0003Nn-Q9 for ged-emacs-devel@m.gmane.org; Fri, 12 Aug 2011 22:29:30 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qs3yZ-0003NX-EM for emacs-devel@gnu.org; Fri, 12 Aug 2011 22:29:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qs3yY-0004T6-6q for emacs-devel@gnu.org; Fri, 12 Aug 2011 22:29:27 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25008 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qs3yY-0004T2-2j for emacs-devel@gnu.org; Fri, 12 Aug 2011 22:29:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJvgRU5FxKeo/2dsb2JhbABBp3d4gUABAQQBViMFCws0EhQYDSSIA6gLkiiGRwSfbIQz X-IronPort-AV: E=Sophos;i="4.67,365,1309752000"; d="scan'208";a="130887354" 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; 12 Aug 2011 22:29:24 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D37AD660CF; Fri, 12 Aug 2011 22:29:23 -0400 (EDT) In-Reply-To: <4E45330C.9060801@gmx.at> (martin rudalics's message of "Fri, 12 Aug 2011 16:05:00 +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.181 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:143184 Archived-At: >> (defun display-buffer (&optional buffer action) >> "Display BUFFER in some window." >> (let* ((user-action >> (assq-regexp (buffer-name buffer) display-buffer-alist)) >> (functions (append (car display-buffer-overriding-action) >> (car user-action) >> (car action) > Here the user has only two choices: Either accept the (car action) with > its alist or use its own (car user-action) with its own alist. No: the alist passed to the function is built by combining the user's and the caller's. The only thing the user's FUNCTION doesn't know is the caller's FUNCTION, although it can fallback to it by retuning nil. >> (defun display-buffer-other-window (buffer alist) >> (let ((pop-up-windows t) >> (special-display-buffer-names nil) >> (special-display-regexps nil) >> (same-window-buffer-names nil) >> (same-window-regexps nil)) >> (emacs23-display-buffer buffer))) > IIUC this is the Emacs23 compatible version skillful users can override > by supplying their own version. This is a sample function that can be used in message-mail-other-window to maximize backward compatibility. > I'm not quite sure how they would indicate such a preference via > `display-buffer-alist' Not sure what "such a preference" refers to. > but apparently the "function that takes a buffer and returns > a boolean" together with some knowledge about the command that is > currently executed should allow them to do that. They can either recognize the buffer name via the regexp, or the buffer's major-mode (yes, the latter requires a function that takes the buffer and returns non-nil iff the major-mode is the right one). I don't think that "knowledge about the command that is currently executed" is something we want to provide because it's too messy. > My basic problem with your approach is the following: When we write a > `display-buffer-near-minibuffer' function that reuses the bottom window, > we have two choices wrt evening window heights - do it or don't do it. You're referring to the following point, I think: - the display method has to handle everything, there's no common/shared postprocessing. The way I think we would handle it is by making most/all display-buffer- function finish by calling a display-buffer-post-process function, passing it the ALIST. So the ALIST may include something like (even-window . height) to specify whether and how to even windows. > someone who wants the opposite behavior. And you will propose to > respect the value of the good old `even-window-heights' option in > `display-buffer-near-minibuffer'. Why would I be not surprised? I don't see any reason why a brand new method such as display-buffer-near-minibuffer should obey obsolete config vars. > As a next step suppose Chong wants to adjust the height of the new > window created by `display-buffer-near-minibuffer' calling, for example, > `fit-window-to-buffer'. We'll soon find someone who dislikes this > behavior and wants `display-buffer' to leave the new height alone. So > someone will propose to add a new user option to turn that > behavior off. If someone suggest it, it's fine: we can just answer by adding a `fit-window' parameter in the ALIST to control this behavior. > And people will continue adding new options as they did with > special-display-..., same-window-..., display-buffer-reuse-frames, and > display-buffer-mark-dedicated. I don't see any reason why that should be the case. > The `display-buffer-alist' idea was to radically put an end to that. > This means that such options can be added _exclusively_ via the alist > and no new variables must be introduced. And obviously it would have > prompted users to customize it in order to get the behavior they want. > But the interaction between options would have been based on a strict > priority. Emacs 23 options are not manageable in this regard. AFAICT my proposal shares the same goal and the same property in this regard. > Most of what you propose above is easily available in Emacs 23 via > `special-display-regexps'. Nope. > An application would just temporarily add > the buffer, the function, and the alist to the head of that and get the > behavior without setting any arguments. But then the user can't override it without a lot of effort. My proposal fixes this problem just as well as yours. > Is it really worth inventing a new `display-buffer' in order to > resolve such cosmetic issues? I don't understand the question. To get back to my suggestion, I think it's really not that different from your code. We can largely provide the same predefined methods (just that things like the `reuse-window' symbol turns into a function `display-buffer-reuse-window', forcing the code to be more modular) and let them handle the same set of arguments and parameters (tho the args to `reuse-window' need to be turned into named parameters). Admittedly, you won't be able to do the equivalent of ((reuse-window foo bar) (reuse-window titi toto)) because the args passed to FUNCTIONs are the same for each FUNCTION, so if a FUNCTION appears twice both occurrences will behave identically. Stefan