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: Wed, 27 Jul 2011 18:10:05 +0200 Message-ID: <4E30385D.9010600@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> 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 1311783035 2835 80.91.229.12 (27 Jul 2011 16:10:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2011 16:10:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 27 18:10:31 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 1Qm6go-0003dz-Dv for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 18:10:30 +0200 Original-Received: from localhost ([::1]:42549 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6gn-0007gz-GD for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2011 12:10:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qm6gk-0007gu-JX for emacs-devel@gnu.org; Wed, 27 Jul 2011 12:10:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qm6gj-0006MV-4L for emacs-devel@gnu.org; Wed, 27 Jul 2011 12:10:26 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:46032) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qm6gi-0006K3-Jr for emacs-devel@gnu.org; Wed, 27 Jul 2011 12:10:25 -0400 Original-Received: (qmail invoked by alias); 27 Jul 2011 16:10:08 -0000 Original-Received: from 62-47-51-135.adsl.highway.telekom.at (EHLO [62.47.51.135]) [62.47.51.135] by mail.gmx.net (mp007) with SMTP; 27 Jul 2011 18:10:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19iM1Ffv4Ni38nMqZ0OioXkAzDGuae4tfDVTzzy7J L7kQQS2qYhHtov User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87r55cjvef.fsf@stupidchicken.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:142397 Archived-At: >> 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. > > Because that would simplify the meaning of both variables, by making > every specifier be a particular way to finding a window to display > in---with no exceptions. This is not an argument for using two variables. The "making every specifier be a particular way to finding a window to display in---with no exceptions" can be applied to the current one variable approach as well. > One cost is that, from your previous message, it conflicts with using a > plist syntax like > > (display-buffer buf > '((reuse-window :buffer same :window other) > (pop-up-window :root lru :side right :min-width 10))) ^^^^^ :window It conflicts only in the sense that a value may be non-scalar like a list because you would have to say something like '((reuse-window :window-buffer-frame (other same))) instead. But a list-like value would be needed anyway for the `pop-up-frame-alist' specifier. > This syntax is (IMO) much more readable. It is easy to guess what every > element means---one problem I have with the current design is that I > have to delve into the docstring to work out what the different elements > and special tags mean. And it has the advantage of similarity with > other facilities in Emacs, like defface specs. Agreed. > I like the display specifier argument to `display-buffer' (with the > aboves changes to the syntax to make them easier to understand); it > seems like a real improvement in the way Lisp programs handle window and > buffer switching. > > What I find problematic is `display-buffer-alist' and specifier merging. As I explained earlier, you don't have to merge specifiers for processing `display-buffer-alist'. If you really want to avoid that, I can fill in the unspecified elements so there's a 100% guarantee that no merging occurs within the elements of `display-buffer-alist'. Which means that the above specifiers would become semantically equivalent to '((reuse-window :buffer same :window other :frame nil :even-sizes t :dedicated nil :dedicate nil :no-other-window nil) (pop-up-window :window lru :side right :min-height 40 :min-width 10 :desired-height nil :desired-width nil :split-unsplittable nil :no-other-window nil)) But if you want to process the `display-buffer' argument, you have to merge. You can't ask all applications that call `display-buffer' to provide all possible specifiers in the argument. So you have to merge in the rest from `display-buffer-alist' or `split-height-threshold', `special-frame-alist', `pop-up-frame-alist', .... And I can't merge in default specifiers as for `display-buffer-alist' because I have to remain compatible with the Emacs 23 behavior where option values are merged in. > I don't like the idea that each specifier lacks a self-contained > meaning, because it can be modified by other specifiers. IIUC, even > with these complications it's still not as flexible as real Lisp code > (e.g. in situations where you want to merge in a specifier if and only > if the original specifier had some specific form). You would have to give me an example here. > My inclination would be to keep the display specifier argument to > `display-buffer', switching to the plist syntax, but leave out > `display-buffer-alist' until we can work out a better way to do merging > (e.g. in 24.2). I don't understand you. If we want to process the display specifier argument, we have to merge. If, with Emacs 23, the second argument of `display-buffer' is non-nil, all `display-buffer' does is to mark the selected window as not usable. It merges in the values of all relevant options wrt finding a suitable "other" window. Note that Emacs 23 even merges when you don't provide the argument. For example, the call in `message-mail-other-window' (let ((pop-up-windows t) (special-display-buffer-names nil) (special-display-regexps nil) (same-window-buffer-names nil) (same-window-regexps nil)) (message-pop-to-buffer (message-buffer-name "mail" to)))) merges in the value of `split-height-threshold' (which can have the effect of not popping up a new window but reusing an existing one) and `even-window-heights' (which may adjust the height of a reused window). And, if `pop-up-frames' is non-nil, it will merge in the values of `pop-up-frame-function' and `pop-up-frame-alist' too. > This way, the display specifier functionality is at > least accessible to Lisp programs for 24.1. Do you think this is > feasible, or do you think that it's impractical, e.g. because the plist > syntax is fundamentally incompatible with merging? The display specifier argument is already there. But in its current implementation it gets merged. That is if you call (display-buffer "*scratch*" '((reuse-window other same) (reuse-window other) (reuse-window-even-sizes . t))) the two attempts to reuse another window will both try to even sizes. And if you do (display-buffer "*scratch*" '((reuse-window other same) (reuse-window other))) it will try to even window sizes provided `even-window-heights' is non-nil. So nothing would be gained wrt your concerns. > If so, it might be > good to revert everything and postphone these changes to 24.2. I intend to start doing that by the end of the week ;-) martin