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, 08 Aug 2011 11:10:42 +0200 Message-ID: <4E3FA812.3080009@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> <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> 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 1312794658 7032 80.91.229.12 (8 Aug 2011 09:10:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2011 09:10:58 +0000 (UTC) Cc: Juri Linkov , Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 11:10:54 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 1QqLrK-0004Yp-2z for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 11:10:54 +0200 Original-Received: from localhost ([::1]:42218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqLrJ-0002Kp-HU for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 05:10:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqLrD-0002KL-BG for emacs-devel@gnu.org; Mon, 08 Aug 2011 05:10:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqLrC-0000W9-B3 for emacs-devel@gnu.org; Mon, 08 Aug 2011 05:10:47 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:42510) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QqLrC-0000Vr-0O for emacs-devel@gnu.org; Mon, 08 Aug 2011 05:10:46 -0400 Original-Received: (qmail invoked by alias); 08 Aug 2011 09:10:44 -0000 Original-Received: from 62-47-58-134.adsl.highway.telekom.at (EHLO [62.47.58.134]) [62.47.58.134] by mail.gmx.net (mp006) with SMTP; 08 Aug 2011 11:10:44 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX184844cA644y3G1HcKjPFQRdcpjJ9lUyRK3leoSR/ yxxELm2T/ME8F+ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: 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.22 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:143004 Archived-At: > I'd make a "display method" be a function, i.e. one of > `display-buffer-reuse-window', `display-buffer-pop-up-window', ... > At which point you can get rid of the idea of a "macro specifier" since > function definitions work just as well. At which point you can give up the idea of merging. I meanwhile know that no one here likes the idea of merging specifiers and don't have the slightest intention to fight for it any more. But no one so far has cared to explain how to support all the things people have piled up over the years like split-height-threshold, even-window-heights, or display-buffer-mark-dedicated. I'd be all in favor of functions if you told me how to write a function that within a year has not been rewritten completely because it's oh so important to add a little thingy here and there. >>> (I'll use the word "macro" for now, but we might want to pick another >>> word since "macro" can be confused with keyboard macros.) >> I'd very much appreciate if someone could invent a more useful term for >> these. > > The name exists already, it's called a function definition. It's really > well supported by a lot of Emacs code: you can document those "macros" > in a very simple way, let users get that doc via C-h f, see them work > step by step with edebug, have feedback about their correctness/style > with M-x byte-compile-file, ... We currently have many ways to specify a function for displaying a buffer: `display-buffer-function', `special-display-function', `pop-up-frame-function', `split-window-preferred-function', the function one can specify via `special-display-regexps'. I know of two people who customized the latter - Drew and you. This doesn't strike me as a story of success. >>> - `display-buffer-alist' is an alist that maps a matcher (regexp, >>> label, or matcher function) to an alist of display specifiers. > > If display specifiers are of the form (VAR . VAL), then you presumably > mean "a list of display specifiers" rather than "an alist of ...". It's an alist where the key of each element is a display specifier. >>> - `display-buffer-macro-specifiers' is an alist that maps a "macro >>> specifier" to an alist of display specifiers. It must include a >>> `display-buffer-method' specifier. >> OK. We have to invent a mechanism that makes `display-buffer' work even >> if someone removes more essential associations from the list. The >> SPECIFIERS argument below should be able to reference it safely. > > I hope by now you all know what I think of "macro specifiers". They are what macros are: Rewrite rules for the users' convenience. >> Good. Would `display-buffer-fallback-alist' be constructed from the >> user's Emacs 23 options, from the Emacs 23 default options, or be nil? > > I think that, as much as possible, the old options should only be used > by the old code. Trying to translate them into the new framework is > generally a bad idea. Especially if it may end up influencing the end > design: let's first design something clean and flexible regardless of > details of the old behavior. Then figure out how to provide backward > compatibility, without impacting the design. OK. I agree with the idea to support the old code and its options as fallback and try to get a new behavior. But what I'm missing is a strategy for how to merge-in the re-bindings of the old options within the old _and_ the new code. Things like (defun message-mail-other-window (&optional to subject) "Like `message-mail' command, but display mail buffer in another window." (interactive) (unless (message-mail-user-agent) (let ((pop-up-windows t) (special-display-buffer-names nil) (special-display-regexps nil) (same-window-buffer-names nil) (same-window-regexps nil)) (message-pop-to-buffer (message-buffer-name "mail" to)))) which I intended to rewrite as (defun message-mail-other-window (&optional to subject) "Like `message-mail' command, but display mail buffer in another window." (interactive) (unless (message-mail-user-agent) (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window))) would then become (defun message-mail-other-window (&optional to subject) "Like `message-mail' command, but display mail buffer in another window." (interactive) (unless (message-mail-user-agent) (let ((pop-up-windows t) (special-display-buffer-names nil) (special-display-regexps nil) (same-window-buffer-names nil) (same-window-regexps nil)) (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window))) for approximately as long as how we are supporting the old code. Or am I missing something? > So, as is the case now, your list of specifiers is not truly an alist > (i.e. earlier elements don't override later elements), instead it's > a mix between an alist and an `or block'? > That sounds like a problem. If someone told me how to address the problem of merging specifiers in a different way I'd be all ears. So far people addressed purely cosmetic issues like using a function instead of a macro or a plist instead of an alist. martin