From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: display-buffer-alist simplifications Date: Fri, 5 Aug 2011 10:45:28 -0700 Message-ID: References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> <4E380918.3060806@gmx.at> <4E397611.5020603@gmx.at> <4E3C13D4.9000707@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312566358 18620 80.91.229.12 (5 Aug 2011 17:45:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 5 Aug 2011 17:45:58 +0000 (UTC) Cc: 'Chong Yidong' , emacs-devel@gnu.org To: "'martin rudalics'" , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 05 19:45:51 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 1QpOT0-0005Fm-11 for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2011 19:45:50 +0200 Original-Received: from localhost ([::1]:33258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpOSz-0004Xb-Cw for ged-emacs-devel@m.gmane.org; Fri, 05 Aug 2011 13:45:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpOSw-0004XJ-1H for emacs-devel@gnu.org; Fri, 05 Aug 2011 13:45:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpOSu-0007WN-O3 for emacs-devel@gnu.org; Fri, 05 Aug 2011 13:45:45 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:47795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpOSu-0007WE-HN for emacs-devel@gnu.org; Fri, 05 Aug 2011 13:45:44 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p75HjacU013121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Aug 2011 17:45:38 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p75HjZ7g000375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 17:45:36 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p75HjTvw002135; Fri, 5 Aug 2011 12:45:29 -0500 Original-Received: from dradamslap1 (/10.159.51.236) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Aug 2011 10:45:30 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E3C13D4.9000707@gmx.at> Thread-Index: AcxTiPutWy0Q/V4sSViX1OxEUbKHPwAASxqw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E3C2C43.0042:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 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:142904 Archived-At: > The absurd consequence of this is that with `pop-up-frames' non-nil > `ctl-x-4-map' becomes identical to `ctl-x-5-map' Not quite. A nitpick: It's more correct to say that every buffer-display binding in `ctl-x-4-map' uses another frame by default instead of another window by default - like the bindings in `ctl-x-5-map' do. In particular, it is not the case that every `C-x 5 ' binding necessarily has a `C-x 4 ' counterpart. Binding `C-x 5 ' to `foobar' has no effect on `C-x 4 '. > and `find-file-other-window' an alias for `find-file-other-frame'. Yes. And this is a feature, not just an absurd consequence. Just changing the value of option `pop-up-frames' makes Emacs magically use another frame by default wherever it would normally use another window by default. Pretty good stuff, IMHO. > You won't find any explanation of this phenomena in the doc-strings of > `pop-up-window' and `pop-up-frame' or in the documentation. Not sure what you mean, but this phenomenon is clearly documented, I think. In `(elisp) Choosing Window', the doc for `pop-up-frames' says: This variable specifies whether `display-buffer' should make new frames. If it is non-`nil', `display-buffer' looks for a window already displaying... If it finds such a window... Otherwise it makes a new frame... Otherwise it makes a new frame. Pretty clear, no? But it would also be good (er, would have been good, before the current deprecation of `pop-up-frames') to mention this in at least some of places in the __Emacs__ manual. Emacs users deserve(d) to know about it. E.g.: 1. `(emacs) Visiting', where we describe `C-x 4 f' and `C-x 5 f', and `(emacs) Select Buffer', where we describe `C-x 4 b' and `C-x 5 b' 2. `(emacs) Creating Frames', where we discuss both `C-x 4' and `C-x 5' 3. `(emacs) Pop Up Window', where we describe `C-x 4' as a prefix that means use another window We should in fact (even for Emacs 24) mention also in #3 that `C-x 5' is analogous to `C-x 4' for another frame, and that `pop-up-frames' (or its new equivalent) causes `C-x 4' to use another frame, like `C-x 5'. You say that this is a feature not commonly used. I think you're probably right about that. I can think of two reasons, besides a user preference that is based on adequate knowledge: 1. Insufficient doc. See above. While I think the doc of `pop-up-frames' is unambiguous, I agree that we could have advertised this feature better. There is _nothing_ about it in the Emacs manual, yet we bother to document `ns-pop-up-frames' there! This is (was) a big oversight, IMO. 2. Emacs gotchas, hurdles, and just plain bad behavior wrt frames (as opposed to windows). A user who tries non-nil `pop-up-frames' either abandons it quickly when s?he encounters such obstacles, or s?he (uncommonly) digs in and tries to tweak the code to somehow tame the behavior. IOW, `Emacs Behaving Badly'. Note that #2 has nothing to do with `pop-up-frames'; it is not the fault of that option. It is simply that the Emacs UI has never been made to work well with frames. IMHO. And it's a vicious circle: because Emacs doesn't play well with frames, few users bother to use frames (e.g. non-nil `pop-up-frames'), testing of features wrt frames gets neglected, few improvements get made,... and 'round and 'round we go. You are, I would guess, the person the most knowledgable about Emacs windows and `display-buffer' at this point, yet you yourself have been pretty virgin (I gather) wrt using Emacs with frames. C'est normal. > >> You don't know what `special-display-buffer-names' does > >> unless you read the code of that function. > > > > I don't know what makes you think so. > > The two weeks I spent with Drew trying to understand it. I'm not sure what you're referring to. If I recall (I might have forgotten), you were at first unaware of the possibility of using FUNCTION, which is my use case. But that's all I remember in terms of any difficulty in understanding. And that is in the doc string - no need to consult the code. The doc of `special-display-buffer-names' has always seemed pretty clear to me. I'm sure that you see and understand more cases than I do, which is perhaps where the complexity comes in, but it didn't take me long to understand how to use `special-display-buffer-names' for my use case (FUNCTION), and I never had to look at its code for that - the doc sufficed. IOW, the doc suffices for understanding the FUNCTION use case. Perhaps the doc does not suffice for understanding `special-display-buffer-names' completely. I can't speak to that. But for Drew's use case, which is what you reference above, I think the doc suffices and it doesn't take two weeks to understand. I get the impression that you are pointing to my use of these things as somehow inherently complex. I think rather it is only that my use case (i.e., FUNCTION) was unknown to you at first, and it is no doubt not a common use case. But an uncommon use case does not mean a complex use case.