From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#1806: dired-pop-to-buffer in wrong place Date: Sat, 17 Oct 2009 11:03:07 +0200 Message-ID: <4AD9884B.6000609@gmx.at> References: <87r63gzcap.fsf@jurta.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.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> Reply-To: martin rudalics , 1806@emacsbugs.donarmstrong.com 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: ger.gmane.org 1255771661 28498 80.91.229.12 (17 Oct 2009 09:27:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2009 09:27:41 +0000 (UTC) Cc: 1806@emacsbugs.donarmstrong.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 17 11:27:30 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 1Mz5ZR-0000p2-F9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Oct 2009 11:27:30 +0200 Original-Received: from localhost ([127.0.0.1]:44498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mz5ZQ-0007JN-Te for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Oct 2009 05:27:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mz5ZJ-0007Is-Py for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 05:27:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mz5ZE-0007HS-Lp for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 05:27:20 -0400 Original-Received: from [199.232.76.173] (port=38186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mz5ZE-0007HJ-4d for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 05:27:16 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:54720) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mz5ZD-0005jH-Gp for bug-gnu-emacs@gnu.org; Sat, 17 Oct 2009 05:27:15 -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 n9H9RBWP022619; Sat, 17 Oct 2009 02:27:13 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9H9A70W020207; Sat, 17 Oct 2009 02:10:07 -0700 Resent-Date: Sat, 17 Oct 2009 02:10:07 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 17 Oct 2009 09:10:06 +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.125577019718621 (code B ref 1806); Sat, 17 Oct 2009 09:10:06 +0000 Original-Received: (at 1806) by emacsbugs.donarmstrong.com; 17 Oct 2009 09:03:17 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n9H93Fpo018618 for <1806@emacsbugs.donarmstrong.com>; Sat, 17 Oct 2009 02:03:16 -0700 Original-Received: (qmail invoked by alias); 17 Oct 2009 09:03:08 -0000 Original-Received: from 62-47-32-211.adsl.highway.telekom.at (EHLO [62.47.32.211]) [62.47.32.211] by mail.gmx.net (mp046) with SMTP; 17 Oct 2009 11:03:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18FqOxOm1UF4I2mXUZRcJqCSRp9Y7KKku0gUDsowJ zol2sJpednBnUd User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 17 Oct 2009 05:27:20 -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:32032 Archived-At: >> Renaming the function is trivial. The problem is finding meaningful >> additional "frame-parameters" like 'same-window and 'same-frame > > 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. IIRC all I did was replace "(same-buffer . t)" with "(same-window . t)" when the buffer was supposed to be displayed in the "same" that is "selected" window. Using a term like "same-buffer" didn't strike me as very intuitive and the term "same-window" was already used with similar semantics in the "same-window-..." variables. Moreover I tried to fix the customization type of `special-display-buffer-names' which IIRC didn't work before. Is it that what you mean by "misdesign"? 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 ;-) > 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. >> 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'. >> I'm afraid there are few people with non-nil >> `special-display-buffer-names' already. Making this more complicated >> won't help anyone. > > I don't follow. I suppose the only person who ever sets `special-display-buffer-names' to a non-nil value is you. 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. So if we want users to customize these variables and at the same time application programmers respect users' settings we should rather try to simplify things instead of introducing further dependencies (IMHO). martin