From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Tue, 26 Jul 2011 22:43:20 -0400 Message-ID: <87r55cjvef.fsf@stupidchicken.com> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311734619 15356 80.91.229.12 (27 Jul 2011 02:43:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2011 02:43:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 27 04:43:35 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 1Qlu5v-00067K-6z for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 04:43:35 +0200 Original-Received: from localhost ([::1]:59630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qlu5u-0001K5-Cb for ged-emacs-devel@m.gmane.org; Tue, 26 Jul 2011 22:43:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qlu5r-0001Jz-Ez for emacs-devel@gnu.org; Tue, 26 Jul 2011 22:43:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qlu5m-0003d5-8B for emacs-devel@gnu.org; Tue, 26 Jul 2011 22:43:31 -0400 Original-Received: from vm-emlprdomr-06.its.yale.edu ([130.132.50.147]:46055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qlu5m-0003cw-33 for emacs-devel@gnu.org; Tue, 26 Jul 2011 22:43:26 -0400 Original-Received: from furball (c-76-28-93-216.hsd1.ct.comcast.net [76.28.93.216]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id p6R2hKJr015895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2011 22:43:21 -0400 In-Reply-To: <4E2D34D7.4040002@gmx.at> (martin rudalics's message of "Mon, 25 Jul 2011 11:18:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.147 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:142332 Archived-At: martin rudalics writes: > First of all you would have to give me some idea of what > `display-buffer-fallback-alist' should look like. Should it be > constructed from the same associations as `display-buffer-alist'? Yes, that is the idea. > why do you think it's better to pay for removing the (override . t) > entries (which should be fairly rare BTW) with another variable and a > doc-string that would either have to refer to that of > `display-buffer-alist' or replicate most of the latter. Because that would simplify the meaning of both variables, by making every specifier be a particular way to finding a window to display in---with no exceptions. >> Having gone through these examples, I am convinced that the cost of >> this design outweighs the benefits. > > Can you tell me what you mean by "cost of the design" and how exactly > you want to avoid that cost. You cannot avoid merging specifiers > unless you duplicate each and every component like `even-sizes' in > each and every specifier. In the latter case the cost of maintaining > an option like `display-buffer-alist' would clearly outweigh any > benefits gained by making the design less expensive. One cost is that, from your previous message, it conflicts with using a plist syntax like (display-buffer buf '((reuse-window :buffer same :window other) (pop-up-window :root lru :side right :min-width 10))) This syntax is (IMO) much more readable. It is easy to guess what every element means---one problem I have with the current design is that I have to delve into the docstring to work out what the different elements and special tags mean. And it has the advantage of similarity with other facilities in Emacs, like defface specs. > Now shouldn't we rather back out all buffer display changes I've > applied recently and revert to using the old Emacs 23 options? I like the display specifier argument to `display-buffer' (with the aboves changes to the syntax to make them easier to understand); it seems like a real improvement in the way Lisp programs handle window and buffer switching. What I find problematic is `display-buffer-alist' and specifier merging. I don't like the idea that each specifier lacks a self-contained meaning, because it can be modified by other specifiers. IIUC, even with these complications it's still not as flexible as real Lisp code (e.g. in situations where you want to merge in a specifier if and only if the original specifier had some specific form). My inclination would be to keep the display specifier argument to `display-buffer', switching to the plist syntax, but leave out `display-buffer-alist' until we can work out a better way to do merging (e.g. in 24.2). This way, the display specifier functionality is at least accessible to Lisp programs for 24.1. Do you think this is feasible, or do you think that it's impractical, e.g. because the plist syntax is fundamentally incompatible with merging? If so, it might be good to revert everything and postphone these changes to 24.2.