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: Tue, 02 Aug 2011 16:24:23 +0200 Message-ID: <4E380897.5000406@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> 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 1312295078 23488 80.91.229.12 (2 Aug 2011 14:24:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2011 14:24:38 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 16:24:32 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 1QoFtX-0002pE-RA for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 16:24:32 +0200 Original-Received: from localhost ([::1]:47273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoFtX-00075S-70 for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2011 10:24:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoFtV-00075M-7f for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:24:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoFtU-00076T-1O for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:24:29 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:49446) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QoFtT-00076L-IC for emacs-devel@gnu.org; Tue, 02 Aug 2011 10:24:27 -0400 Original-Received: (qmail invoked by alias); 02 Aug 2011 14:24:25 -0000 Original-Received: from 62-47-54-84.adsl.highway.telekom.at (EHLO [62.47.54.84]) [62.47.54.84] by mail.gmx.net (mp064) with SMTP; 02 Aug 2011 16:24:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+nVQN9DJinzQR6IhoA4Pk/22uCZQzEmjal1DRMFI C4oTbAlA15GvI1 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87oc092gy0.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:142699 Archived-At: > 1) Expose all the internal "variables" currently living inside > display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes > and pop-up-window-min-height. I suppose that what you mean here is to rewrite Emacs 23 options like `even-window-heights' and `split-height-threshold' where applicable. These values would serve as the default values for any buffer, that is, there would be no distinction between *Help* and *Info* buffers wrt the minimum height of their windows, I presume. Then the applications could override this by their plists and `display-buffer-alist' would override the application's and the default values. Is that correct? One idea of `display-buffer-alist' was to concentrate all display buffer related variables into one and make any additions inside that variable. A basic drawback of the <= Emacs 23 approach was that we always added variables like `display-buffer-reuse-frames' and `display-buffer-mark-dedicated' with very ad hoc semantics many people don't understand. (Maybe I exaggerate here but at least I don't understand them as recent problems with reusing frames and marking reused windows as dedicated shows.) Personally, I hardly ever had problems with displaying buffers because I don't do that often. So if people agree that exposing these variables is TRT I can principally do that. For this purpose we'd first have to go through each of these variables and decide (1) on a suitbale name (and possibly any aliases), and (2) whether and what should be changed in the possible values and how to represent them. Finally we'd have to decide what to do about options that don't exist yet like `pop-up-window-set-height'. What I probably cannot do is incorporating buffer specific options like `special-display-regexps' into this scheme. These apply individually to buffers and do require the merge-in behavior of things like `even-window-heights' you probably want to avoid by exposing the internal variables. I'm obviously all ears for any suggestions how to do that. (If there are any doubts about why these are problems recall that `display-buffer-alist' is nothing else but a generalization of `special-display-regexps' and `special-display-buffer-names'.) > 2) Make the "display methods" specifier just another one of these > variables, e.g. call it `display-buffer-method'. Would this discriminate buffers via regexps and how would you apply the "try reusing a window and if that fails pop up a new one ..." here? I assume you'll say "no" to both of them. > 3) Change display-buffer-alist so that it is just a method of overriding > Lisp variables during display-buffer. That is to say, it is an alist > where each element has the form (MATCHER . OVERRIDES). The first > entry with matching MATCHER takes effect; its OVERRIDES is an alist > where each element has the form (VAR . VALUE), which says to bind VAR > to VALUE. > MATCHER will include matching the buffer name to a regexp, but we can > add more complex conditionals later, e.g. a way to specify that a > variable must have a certain value. > > In this scheme, there is no interaction between elements of > display-buffer-alist, and no interaction between specifiers apart from > the familiar behavior of rebinding Lisp variables. Martin's example > would be implemented like the following: > > (setq pop-up-window-min-height 15) > > (setq pop-up-window-choice '((largest) (lru))) > > (setq display-buffer-method '(pop-up-window)) > > (setq > display-buffer-alist > '((((regexp . "\\`\\*Help\\*\\'")) > (pop-up-window-set-height . fit-window-to-buffer)) > (((regexp . "\\`\\*.+\\*\\'")) > (pop-up-window-set-height . 20)))) Could you give an example of how to specify reusing a window along these lines? And of how to specify the above mentioned "try reusing a window and if that fails pop up a new one ..."? Would we write, for example, (setq display-buffer-method '(pop-up-window reuse-window)) If so how would we express to first find another window showing the same buffer and then another window showing another buffer? martin