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: Sat, 06 Aug 2011 15:29:04 +0200 Message-ID: <4E3D41A0.6000105@gmx.at> 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312637361 9990 80.91.229.12 (6 Aug 2011 13:29:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 13:29:21 +0000 (UTC) Cc: 'Chong Yidong' , 'Stefan Monnier' , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 15: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 1QpgwG-0005Jd-7L for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 15:29:16 +0200 Original-Received: from localhost ([::1]:33296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpgwF-0000GH-HM for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 09:29:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpgwC-0000Ft-4v for emacs-devel@gnu.org; Sat, 06 Aug 2011 09:29:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpgwA-0004LL-B6 for emacs-devel@gnu.org; Sat, 06 Aug 2011 09:29:12 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:40764) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qpgw9-0004LE-VM for emacs-devel@gnu.org; Sat, 06 Aug 2011 09:29:10 -0400 Original-Received: (qmail invoked by alias); 06 Aug 2011 13:29:07 -0000 Original-Received: from 62-47-32-167.adsl.highway.telekom.at (EHLO [62.47.32.167]) [62.47.32.167] by mail.gmx.net (mp021) with SMTP; 06 Aug 2011 15:29:07 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18eeW4SHkQegROC8Gq22hVRoKFILy+M1n8VUdrZg1 vjtDpppU6WZn92 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: 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:142927 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. I was trying to exaggerate. > 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. Pretty heavy stuff, IMHO. I can see two types of users: - Those who don't work with multiple frames never use C-x 5 and don't use `find-file-other-frame'. - Those who do work with multiple frames set `pop-up-frames' to t and never use C-x 5 or `find-file-other-frame' because C-x 4 and `find-file-other-window' works for them as god intended. Now maybe there are users out there who usually work in a single frame and occasionally want to show a file in another frame via C-x 5 f. Then we could easily imagine users who usually work with multiple frames and occasionally want to pop up a window to show a file in the same frame. But C-x 4 f doesn't work for them in this case. That's what I consider absurd. >> 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? No. Because when I type C-x 4 f, I might not have the slightest idea that `find-file-other-window' ends up calling `display-buffer' and `pop-up-frames' will affect the placement of the window. > 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'. But do we really need two different keymaps? If the intention was to confuse users sure, but ... > 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, What's needed? > 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. All you say is true. But to implement frames well you have to interact with window managers and if you follow Jan's conversations with various users you will see that this is a bottomless endeavour. >> >> 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. I wasn't (I can easily prove that because the corresponding code was in the trunk before your first complaint ;-)). But I got the calling convention wrong (and I won't comment it here because people would immediately ban me from this list). > 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. That part is in the doc-string. > 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. Obviously so, because your use case is the only one that disregards all other features: It either produces a window or it fails. Disregarding the murked translation of the call within `special-display-popup-frame' it is also the only change to the special-display stuff I consider reasonable and that's why I tried to 1-to-1 mirror it via the `function' specifier of `display-buffer-alist'. > IOW, the doc suffices for understanding the FUNCTION use case. It does. > 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. It is "complex" because it is one of the few uses case I'm aware of where something special like a function is needed. You can't do what you want by using the other buffer display options of Emacs 23 alone. But let's agree on one thing: There are few users who want to _and_ know how to use this feature. martin