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: Sun, 07 Aug 2011 10:32:09 +0200 Message-ID: <4E3E4D89.5010005@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> <4E3D41A0.6000105@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 1312705947 6825 80.91.229.12 (7 Aug 2011 08:32:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2011 08:32:27 +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 Sun Aug 07 10:32:23 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 1QpymU-0006kh-BQ for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2011 10:32:22 +0200 Original-Received: from localhost ([::1]:60981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpymT-0002Nr-MP for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2011 04:32:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpymQ-0002Nb-Om for emacs-devel@gnu.org; Sun, 07 Aug 2011 04:32:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpymP-0005a3-FZ for emacs-devel@gnu.org; Sun, 07 Aug 2011 04:32:18 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:37774) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QpymP-0005ZT-2l for emacs-devel@gnu.org; Sun, 07 Aug 2011 04:32:17 -0400 Original-Received: (qmail invoked by alias); 07 Aug 2011 08:32:13 -0000 Original-Received: from 62-47-46-45.adsl.highway.telekom.at (EHLO [62.47.46.45]) [62.47.46.45] by mail.gmx.net (mp032) with SMTP; 07 Aug 2011 10:32:13 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/dK21DkIjdF/hEd5ea1qm8CifOO9a0xkYB3jvhQI 0w6L4CrGujwWqj 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, 2) 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:142956 Archived-At: >> > 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. > > Dunno what that means. But the ability to make Emacs use other-frame rather > than other-window by default, just by toggling a variable value, is a definite > plus, and in the spirit of both Emacs and Lisp. Toggling the variable value changes the semantics of the command `foo-other-window' to that of `foo-other-frame' iff the `foo-other-window' command invokes `display-buffer'. If it doesn't, it might do anything it wants. The semantics of "-other-window" is nowhere defined within Emacs. `org-switch-to-buffer-other-window', for example, specially binds `pop-up-frames' to nil in order to achieve its "other window" behavior. And the definite plus is a definite minus for those who document the behavior. Take these (obviously wrong) excerpts from the Emacs manual: 20.4 Displaying in Another Window ================================= `C-x 4' is a prefix key for commands that select another window (splitting the window if there is only one) and select a buffer in that window. Different `C-x 4' commands have different ways of finding the buffer to select. or `C-x 4 f' (`find-file-other-window') is like `C-x C-f' except that the buffer containing the specified file is selected in another window. The window that was selected before `C-x 4 f' continues to show the same buffer it was already showing. If this command is used when only one window is being displayed, that window is split in two, with one window showing the same buffer as before, and the other one showing the newly requested file. >> 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. > > Correct. That reasoning I understand. > > All I can say is that in practice, and speaking for myself, I don't miss it. > Whenever I want a new window in the same frame I use C-x 2 etc. Adopting your reasoning we could simply bind C-x 5 to `make-frame' and do away with the entire C-x 5 map and the associated descriptions. > (But I will add > that there are still some hard-coded Emacs pop-up windows that do not pop up as > a separate frame, even when `pop-up-frames' is non-nil.) Are you sure it's not rebound by the application in these cases? > But I probably would not oppose making this reciprocal: When `pop-up-frames' is > non-nil, then `C-x 5' would use other-window instead of other-frame. My guess > is that this has never come up because no one who uses non-nil `pop-up-frames' > (and we are probably few) really misses it. But why not? ;-) > And if possible, in the end I would like to see something very simple like > `pop-up-frames' that lets a user simply convert Emacs magically to using frames > by default - as before. That simplicity for a user is a real plus. If we have > to sacrifice that simplicity, it will be too bad. > > And personally, FWIW, I am in _favor_ of being able to dynamically let-bind > (some) variables to change behavior at a distance. That is useful for users of > all kinds, at all levels. Having to fiddle with things inside the details of > function bodies - changing args in calling sequences etc. is not what Emacs (and > Lisp, in general) is about. We can leave in any magic people are used to. But then you won't find anyone who implements things like showing the ispell buffer in a separate frame or removing the frame showing dired's marked files when it's no more needed. Which means that the current `split-window' or `save-window-excursion' based code is effectively carved in stone. martin