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, 25 Jul 2011 11:18:15 +0200 Message-ID: <4E2D34D7.4040002@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> 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 1311585510 26403 80.91.229.12 (25 Jul 2011 09:18:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2011 09:18:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 11:18:25 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 1QlHIv-00011J-5U for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2011 11:18:25 +0200 Original-Received: from localhost ([::1]:39038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlHIu-0007Ni-CY for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2011 05:18:24 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlHIq-0007Nc-RR for emacs-devel@gnu.org; Mon, 25 Jul 2011 05:18:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlHIp-0007Ae-7O for emacs-devel@gnu.org; Mon, 25 Jul 2011 05:18:20 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:45984) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QlHIo-0007AZ-Ql for emacs-devel@gnu.org; Mon, 25 Jul 2011 05:18:19 -0400 Original-Received: (qmail invoked by alias); 25 Jul 2011 09:18:16 -0000 Original-Received: from 62-47-54-207.adsl.highway.telekom.at (EHLO [62.47.54.207]) [62.47.54.207] by mail.gmx.net (mp072) with SMTP; 25 Jul 2011 11:18:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19BgZtmlyRB7Z/zkD0/JwfLpuzK2mnK+QD0N0O5RD RPaOkXwdfWXsEW User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <878vrnweju.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.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:142274 Archived-At: > The topic at hand is whether `display-buffer-alist' should "merge" into > the display specifier supplied to `display-buffer'. Let's put aside the > question of whether the Emacs 23 system is or is not complicated. The question whether and how to merge such a specifier is central to the question whether we should change the semantics of the not-this-window argument of `display-buffer' at all. If we prefer to not do that, then I should be able to provide a working version of `display-buffer' from last autumn which might be quite usable as fallback. Since most people do find `display-buffer-alist' much too complicated and Stefan is apparently opposed to almost all new features it provides, we should seriously consider reverting the changes introduced by buffer display specifiers. In this context it makes also sense to discuss whether the Emacs 23 system is or is not complicated. > So, IIUC, this converts the same-window specifier > > ((reuse-window same nil nil)) > > to > > ((reuse-window other nil 0) > (reuse-window same nil nil) > (reuse-window same)) > > Right? Although I'd formulate it the other way round I can live with your interpretation. > This form of "merging" can be eliminated by providing a > `display-buffer-fallback-alist', removing the need for (override . t) > and one source of unwanted interaction between specifiers. 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'? If so, then 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. > Here is the basic point. You're arguing for a buffer display specifier > syntax that consists of interacting elements, because this syntax allows > `display-buffer-alist' to "merge with" or "influence" the specifiers > supplied to `display-buffer'. Yes. The design is still that of Emacs 23 where the `not-this-window' argument gets interpreted by `display-buffer' as (1) reuse another window with the value of `even-window-heights' merged in, (2) pop up a new window with the values of `split-window-preferred-function' merged in and that of `split-...-threshold' influencing it, or (3) pop up a frame with the value of `pop-up-frame-alist' merged in. > 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. > It is far more important to use a syntax that is easy to understand. > If I have a list of specifiers > > (A B C ...) > > that should mean "try A; if that fails, try B; if that fails, try C". Nothing in the current design prevents you from writing precisely that. > And not a situation where certain B's are not things to try, but instead > are tags that modify how A behaves, or tags that say how to merge this > list with the argument to `display-buffer', etc. This kind of > pseudo-programming language is not a good fit to the Emacs concept of > customizable options; the traditional way of providing customizable > programming logic is with hooks and abnormal hooks. It's completely up to the users whether they want that or not. Users who don't want a certain B to modify how A behaves can include in A all necessary ingredients to make sure that B never affects the behavior of A. But why should other users who do want B to affect the behavior of A pay for that by being forced to replicate all these specifiers in A? > The point is that `info-other-window' can call display-buffer as > > (display-buffer buf specifiers 'info-other-window) > > so the user could override this with > > (setq display-buffer-alist > '((info-other-window replacement-spec))) > > This obviates the need to provide the specifier merging functionality, > without forcing Lisp code like `info-other-window' to bind > display-buffer-alist to nil. Sigh. You wanted the specifiers of `display-buffer-alist' to always override those provided by the application. If a user's `display-buffer-alist' contains a regexp entry for *info* buffers telling to display them always in the same window, the label passed by `info-other-window' won't have any effect and the buffer will be shown in the same window. So the user, in addition, has to provide a `display-buffer-alist' entry based on the `info-other-window' label which does nothing but replicate what is said in the argument, namely "yes, please do display the buffer in another window". Which means that users who dare to specify a regexp entry for `display-buffer-alist' also have to specify an entry for each and every `display-buffer' call with an application provided argument. 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 could easily incorporate the changes Stefan mentioned earlier and shortly sketched in http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00461.html and we'd forget about the whole new semantics of the second argument of `display-buffer' and more sophisticated ways to tweak `display-buffer'. Eventually somebody could quietly look into this and apply whatever people find more suitable and you could quietly go on with the pretest. martin, who begins feeling to weak to delve into this subject again.