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: Sun, 24 Jul 2011 19:05:42 +0200 Message-ID: <4E2C50E6.3020103@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> 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 1311527159 14605 80.91.229.12 (24 Jul 2011 17:05:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 17:05:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 24 19:05:55 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 1Ql27m-0001PX-EQ for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2011 19:05:54 +0200 Original-Received: from localhost ([::1]:35975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ql27i-0006Z3-Hc for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2011 13:05:50 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ql27f-0006Yl-S4 for emacs-devel@gnu.org; Sun, 24 Jul 2011 13:05:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ql27e-00048j-8p for emacs-devel@gnu.org; Sun, 24 Jul 2011 13:05:47 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:53808) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Ql27d-00048a-HT for emacs-devel@gnu.org; Sun, 24 Jul 2011 13:05:46 -0400 Original-Received: (qmail invoked by alias); 24 Jul 2011 17:05:44 -0000 Original-Received: from 62-47-35-136.adsl.highway.telekom.at (EHLO [62.47.35.136]) [62.47.35.136] by mail.gmx.net (mp023) with SMTP; 24 Jul 2011 19:05:44 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18LEV5P57sL+ZitFcmvIzdejqs0kCA+zKjAOzLmz6 Q5a7MFhTGx3rnE User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <8739hvu6lh.fsf@stupidchicken.com> 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.23 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:142264 Archived-At: >> (setq >> display-buffer-alist >> '((((regexp . ".*")) >> (reuse-window other same) >> (reuse-window-even-sizes . t) >> (reuse-window other other) >> (reuse-window-even-sizes . nil)))) > > This is not clean. The specifiers interact with one another, and their > ordering affects the behavior of other specifiers. The ordering is important, yes. But the ordering is fully controlled by the user. With Emacs 23 the ordering was implicily specified by the coding and was explained only in the Elisp manual. Despite the fact that Eli spent some time writing the documentation, we had complaints that it still left out many things. > Semantically it is > even more complicated than font-lock-keywords---which isn't even > user-customizable. The semantics of `display-buffer-alist' are certainly cleaner than the semantics of Emacs 23 options. With `display-buffer-alist' you only specify what _shall_ be done. You don't care about what shall be avoided. OTOH Emacs 23 options provide a mixture of what should be done and what should be avoided. For example, Emacs 23 doesn't allow the user to directly specify that a buffer should not go to the selected window. The not-this-window argument was provided specifically for applications to state that fact. Users had to write a special-display function to do that. > For example, suppose I want Emacs to (i) always avoid displaying in the > current window first, even if the display-buffer specifier says so; Please don't use the formulation "avoid" with `display-buffer-alist'. Try to formulate in a positive sense: Which window shall be reused instead when the application's specifer says to use the selected one? > (ii) > when trying to reuse a window that already has the desired buffer on the > current frame, also try looking in other frames at the same time; This is not very clear (and was even less so in Emacs 23, but that's a separate story). Please say which frames it should investigate in which order - "at the same time" is too vague. Also say whether in (ii) you would still insist on using another window but the selected one. > and > (iii) if all other specifiers fail, fall back on using the current > window. How is that done? Tell me what's missing in the form (setq display-buffer-alist '((((regexp . ".*")) (reuse-window other nil 0) (override . t) (reuse-window same)))) for a call like (display-buffer "*scratch*" 'same-window) >> Impossible. The first consequence of this would be applications >> rebinding `display-buffer-alist' to nil around `display-buffer' calls. >> How would you implement `info-other-window' or `find-file-other-frame' >> when the user has a `display-buffer-alist' entry for *Info* or the file >> in question? > > Isn't that what you introduced labels for? Labels should be used when the application proposes to do something special for a specific command or function but theuser wants it to do something different. If everything the user specifies already means to do something different, we would have to invert the meaning of labels in the sense of "if the label matches don't do something different but do what the application wants". martin