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: Wed, 03 Aug 2011 16:29:07 -0400 Message-ID: <871ux2nsrw.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> <87r55cjvef.fsf@stupidchicken.com> <87sjpsnerd.fsf@mail.jurta.org> <4E355D2C.40709@gmx.at> <87k4axzg7j.fsf@mail.jurta.org> <87oc092gy0.fsf@stupidchicken.com> <4E380897.5000406@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312403360 26950 80.91.229.12 (3 Aug 2011 20:29:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2011 20:29:20 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 03 22:29:16 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 1Qoi44-0004MZ-6n for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 22:29:16 +0200 Original-Received: from localhost ([::1]:37262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoi43-00061o-Og for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 16:29:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoi40-00061T-Dt for emacs-devel@gnu.org; Wed, 03 Aug 2011 16:29:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qoi3z-0001B7-9g for emacs-devel@gnu.org; Wed, 03 Aug 2011 16:29:12 -0400 Original-Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]:41535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qoi3z-0001B1-7r for emacs-devel@gnu.org; Wed, 03 Aug 2011 16:29:11 -0400 Original-Received: from furball ([128.36.14.213]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p73KT7mb007817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Aug 2011 16:29:08 -0400 In-Reply-To: <4E380897.5000406@gmx.at> (martin rudalics's message of "Tue, 02 Aug 2011 16:24:23 +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.145 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.145 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:142845 Archived-At: martin rudalics writes: > 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. Fair enough. So use `display-buffer-fallback-alist' as Juri said. The main point is to make it so that (i) display specifiers behave like familiar old variable binding, and (ii) there is an easy way to set the default without introducing complex merging sematics. OTOH, this can be implemented internally as local vars---concatenate all the alists from the display-buffer-alist, the display-buffer arg, and display-buffer-fallback-alist into one big alist, then do a destructuring-bind. > Any such thing like `display-buffer-fallback-alist' has to cope with > the variables `special-display-buffer-names' and > `special-display-regexps' which may prescribe individual behavior > based on the names of buffers. There is no "global" default value for > all buffers unless we are prepared to sacrifice compatibility with > Emacs 23. We can specify that these old variables override the new behavior, i.e. `display-buffer-fallback-alist' only applies to buffers not matching `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? > > 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? One way would be to allow display-buffer-method to be a list of macro specifiers, e.g. something like: (setq display-buffer-fallback-alist '((display-buffer-method (other-window-same-buffer other-window)))) (setq display-buffer-macro-specifiers '((other-window-same-buffer (display-buffer-method reuse-window) (reuse-window-buffer same) (reuse-window-window other)) (other-window (display-buffer-method reuse-window) (reuse-window-window other))