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, 18 Jul 2011 20:52:50 +0200 Message-ID: <4E248102.6080904@gmx.at> References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@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 1311015361 5199 80.91.229.12 (18 Jul 2011 18:56:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2011 18:56:01 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 20:55:57 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 1Qisyy-000081-Qc for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 20:55:56 +0200 Original-Received: from localhost ([::1]:52437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qisyx-0000Qs-S2 for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2011 14:55:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QiswR-0008Gm-27 for emacs-devel@gnu.org; Mon, 18 Jul 2011 14:53:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QiswO-0003BY-L3 for emacs-devel@gnu.org; Mon, 18 Jul 2011 14:53:18 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:36873) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QiswN-00038Q-T0 for emacs-devel@gnu.org; Mon, 18 Jul 2011 14:53:16 -0400 Original-Received: (qmail invoked by alias); 18 Jul 2011 18:52:55 -0000 Original-Received: from 62-47-51-119.adsl.highway.telekom.at (EHLO [62.47.51.119]) [62.47.51.119] by mail.gmx.net (mp015) with SMTP; 18 Jul 2011 20:52:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1//hVt00oX/NcFgOznjOEowkqgadekNWYwaANQYco YtoddwB71RjepI 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.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:142134 Archived-At: > We can combine them with a "a\\|b\\|c" regexp. I wonder whether users who don't know much about regexps would like such a thing but it can be obviously done. > I don't even know why you added the `label' case, so I don't think we > should worry about adding more types. The label case would specify the calling function so users can change the behavior if the name of the buffer is not distinctive enough. It can be easily removed if people think it's not needed. > More generally, I have the impression it's a bit overengineered. > I can't find any comment anywhere that explains/justifies > the complexity. Could you explain it here to help us refine the design > (or to add the explanation to the code)? The complexity derives from the complexity of `display-buffer' and probably from an attempt to handle each possible variant. Emacs 23 was not less complex in this regard: If you wanted to display a buffer in the same window, you had at least four options to say so, namely `same-window-buffer-names', `same-window-regexps', `special-display-buffer-names' and `special-display-regexps' all with a separate documentation of the individual behavior, leaving mostly unexplained which option prevailed. `display-buffer-alist' provides one specifier to do that. Do you really think `display-buffer-alist' is more complex than the four options listed above taken together? I don't know how many times I went through the code of `special-display-buffer-names' but I know that I still don't understand it. > AFAIK, the only feature I know to be needed compared to what was > provided in Emacs-23 is a parameter `where' to display-buffer which > generalizes the `same-frame' parameter by turning it into a value of the > `where' and allowing other values such as `same-window' or > `near-minibuffer'. Admittedly, atomic windows and side windows provide some considerable additional complexity but there have been frequent requests that putting a buffer into a window should practically always pass through `display-buffer'. Although I don't necessarily share that opinion I tried to incorporate them in the design. And people don't have to care about these as long as they don't need them. But I have no problems removing support for them either. There have been requests that `display-buffer' should be able to set the size of a popped-up window and optionally specify a function to set the height by calling a function like `fit-window-to-buffer'. These can be easily removed and we get a doc-string that is 35 line shorter. So we've got plenty of room for down-engineering `display-buffer-alist'. Just tell me what you want to remove. martin