From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#1806: dired-pop-to-buffer in wrong place Date: Sat, 17 Oct 2009 21:40:01 -0400 Message-ID: References: <87r63gzcap.fsf@jurta.org> <4ACB0646.5030102@gmx.at> <87r5tg9mhb.fsf@mail.jurta.org> <87tyy4qu08.fsf@mail.jurta.org> <871vl6x5un.fsf@mail.jurta.org> <873a5lzqhi.fsf@mail.jurta.org> <4AD6B592.6090700@gmx.at> <87aazswbp2.fsf@mail.jurta.org> <4AD81B2B.8040805@gmx.at> <4AD87446.4090303@gmx.at> <4AD8A0D7.9060409@gmx.at> <4AD9884B.6000609@gmx.at> Reply-To: Stefan Monnier , 1806@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1255831655 7695 80.91.229.12 (18 Oct 2009 02:07:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2009 02:07:35 +0000 (UTC) Cc: 1806@emacsbugs.donarmstrong.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 18 04:07:27 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MzLB7-0003q9-LF for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2009 04:07:26 +0200 Original-Received: from localhost ([127.0.0.1]:39279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzLB7-00035g-6C for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Oct 2009 22:07:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzLB1-00033y-GU for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 22:07:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzLAw-00031A-KD for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 22:07:18 -0400 Original-Received: from [199.232.76.173] (port=37754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzLAw-000317-Hl for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 22:07:14 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:51668) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MzLAv-0001hP-TI for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 22:07:14 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9I27BnH022441; Sat, 17 Oct 2009 19:07:12 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9I1o3BZ018665; Sat, 17 Oct 2009 18:50:04 -0700 Resent-Date: Sat, 17 Oct 2009 18:50:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 01:50:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125583000917230 (code B ref 1806); Sun, 18 Oct 2009 01:50:03 +0000 Original-Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 01:40:09 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.183]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9I1e7F9016981 for <1806@emacsbugs.donarmstrong.com>; Sat, 17 Oct 2009 18:40:08 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAEcP2krO+IKD/2dsb2JhbACBUdVyhDEEiAU X-IronPort-AV: E=Sophos;i="4.44,579,1249272000"; d="scan'208";a="47749789" Original-Received: from 206-248-130-131.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.131]) by ironport2-out.pppoe.ca with ESMTP; 17 Oct 2009 21:40:02 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C4D1F7FD5; Sat, 17 Oct 2009 21:40:01 -0400 (EDT) In-Reply-To: <4AD9884B.6000609@gmx.at> (martin rudalics's message of "Sat, 17 Oct 2009 11:03:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 17 Oct 2009 22:07:18 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32045 Archived-At: >> As mentioned in some past thread, `same-frame' and `same-window' >> parameters were misdesigned (by yours truly). It should probably be >> a single parameter with values `same-frame' or `same-window' instead. [ "yours truly" means something like "myself" rather than "you". ] [...] > Anyway, the "FRAME-PARAMETERS are pairs of the form (PARAMETER . VALUE)" > paradigm was present in Emacs 22 so I conjecture that any such misdesign > happened before I touched this ;-) The problem is that `same-frame' should not be a PARAMETER but a VALUE. That was the original misdesign. >> Then we'd want to add the values `near-minibuffer' or `contiguous' for >> the dired-pop-to-buffer behavior. For the split-orientation, I'm not >> sure if that same parameter should be used, or if a new one should be >> used instead. > I have no opinion about that because I don't use it. But I'm afraid > that some confusion might result from the fact that "same-window" or > "near-minibuffer" could refer to the "window that shall be split" or to > the "window that shall be used" to display the buffer. There are indeed two questions here: 1- in which area of which frame should the buffer be created. 2- should display-buffer create a new window for it, or should it use an existing window. Maybe these two issues are really orthogonal so they deserve separate PARAMETERS. I.e. one parameter about *where* to display the buffer (same-frame, same-window, near-minibuffer, nearby, ...), and the other about how to display it (reuse-window, create-new-window, or create-new-frame). >>> and how to make them interact with `pop-up-windows' and >>> `pop-up-frames'. >> I don't see much difficulty here. > I do. `pop-up-windows' and `pop-up-frames' are user preferences that > should be observed. The idea that applications can override them in > various ways - other-window > same-window > pop-up-windows is one of > these implicit priority chains `display-buffer' has to resolve - is > already not very helpful in this regard. Giving an application even > more control wrt the behavior of `display-buffer' defeats the purpose of > customizing variables like `pop-up-windows'. The intention of those changes is to let more applications use display-buffer rather than hand-crafted combinations of split-window, switch-to-buffer and things like that, so it should only give more control to the user, not the opposite. > I suppose the only person who ever sets `special-display-buffer-names' > to a non-nil value is you. Could be, but I doubt it. > Application programmers OTOH got used to > sweeping blows like > (let ((special-display-buffer-names nil) > (special-display-regexps nil) > (same-window-buffer-names nil) > (same-window-regexps nil)) > (pop-to-buffer ... > in order to redeem any complications caused by these variables. Yes, such programming should be fixed. Fixing requires making it possible for the application to say what it wants in some other way (more precise) than by rebinding those vars. Things like `same-window' is precisely designed for such uses. Stefan