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: Sun, 18 Oct 2009 12:24:43 +0200 Message-ID: <4ADAECEB.2080101@gmx.at> 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: 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 1255863207 4056 80.91.229.12 (18 Oct 2009 10:53:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2009 10:53:27 +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 Sun Oct 18 12:53:17 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 1MzTO0-0005Ru-GY for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2009 12:53:17 +0200 Original-Received: from localhost ([127.0.0.1]:40828 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzTNz-0002dn-P4 for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2009 06:53:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzTII-0000Yr-H2 for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 06:47:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzTIC-0000WN-U6 for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 06:47:20 -0400 Original-Received: from [199.232.76.173] (port=52241 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzTIA-0000Vd-Su for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 06:47:15 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:36323) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MzTIA-0003H5-Ay for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 06:47: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 n9IAlBtp013757; Sun, 18 Oct 2009 03:47:12 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9IAU5V4010831; Sun, 18 Oct 2009 03:30:05 -0700 Resent-Date: Sun, 18 Oct 2009 03:30:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 10:30:05 +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.12558614949926 (code B ref 1806); Sun, 18 Oct 2009 10:30:05 +0000 Original-Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 10:24:54 +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 n9IAOpw9009921 for <1806@emacsbugs.donarmstrong.com>; Sun, 18 Oct 2009 03:24:53 -0700 Original-Received: (qmail invoked by alias); 18 Oct 2009 10:24:44 -0000 Original-Received: from 62-47-61-9.adsl.highway.telekom.at (EHLO [62.47.61.9]) [62.47.61.9] by mail.gmx.net (mp046) with SMTP; 18 Oct 2009 12:24:44 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18GFe5eu/oGCcIt7Gv8u5f0ieYotFB1tDRvLYKIcf iVcn0nl7g9BVQe User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sun, 18 Oct 2009 06:47: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:32058 Archived-At: > [ "yours truly" means something like "myself" rather than "you". ] I must be suffering from a persecution complex. > 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). That's what I meant. Currently these issues are conflated. > 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. I suppose you mean 'same-window as possible value of NOT-THIS-WINDOW here. Overriding the values of customized variables is problematic. Consider the (let ((window-min-height 1)) paradigm to make a one-line window. This is, inherently, disastrous because it implicitly lets the window that shall be split shrink to one line while the binding is effective although the clear intention of the programmer is to make this affect only the window that shall be created. I think that an application should never bind any variable guarding the windows popup and resizing behavior. For `display-buffer' this means that the entire necessary information should be passed via the NOT-THIS-WINDOW and FRAME arguments. For `split-window' I suppose an explicit size argument should allow to set the size of the respective (old or new) window disregarding the actual `window-min-height' settings and honor these settings for all other windows. martin