From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#1806: dired-pop-to-buffer in wrong place Date: Tue, 25 Sep 2012 11:05:05 +0300 Organization: JURTA Message-ID: <8739261q8h.fsf@mail.jurta.org> References: <87r63gzcap.fsf@jurta.org> <505DBC23.5040907@gmx.at> <87y5k1lhn6.fsf@mail.jurta.org> <505ED4BB.3030103@gmx.at> <87txunj0ej.fsf@mail.jurta.org> <50602A8D.6010203@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348561103 18118 80.91.229.3 (25 Sep 2012 08:18:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2012 08:18:23 +0000 (UTC) Cc: 1806@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 25 10:18:26 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TGQLY-0004jK-5N for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2012 10:18:24 +0200 Original-Received: from localhost ([::1]:48474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGQLS-0005Qf-O4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2012 04:18:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGQLK-0005QK-Le for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 04:18:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGQLE-000733-FU for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 04:18:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGQLE-00072w-C2 for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 04:18:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TGQN8-0005VT-40 for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2012 04:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Sep 2012 08:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1806 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134856119521150 (code B ref 1806); Tue, 25 Sep 2012 08:20:01 +0000 Original-Received: (at 1806) by debbugs.gnu.org; 25 Sep 2012 08:19:55 +0000 Original-Received: from localhost ([127.0.0.1]:54431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGQN1-0005V5-4i for submit@debbugs.gnu.org; Tue, 25 Sep 2012 04:19:55 -0400 Original-Received: from ps18281.dreamhost.com ([69.163.218.105]:56971 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGQMw-0005Uv-PX for 1806@debbugs.gnu.org; Tue, 25 Sep 2012 04:19:52 -0400 Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 2EEDF451CD08; Tue, 25 Sep 2012 01:17:49 -0700 (PDT) In-Reply-To: <50602A8D.6010203@gmx.at> (martin rudalics's message of "Mon, 24 Sep 2012 11:40:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64868 Archived-At: > It's because resizing a window is allowed to steal space from _any_ > other window on the frame. That is, it will preferably steal space from > all other windows in the same combination (the upper window in our > case). But if that is not sufficient, it can steal space from any other > window on the same frame. We could make this optional but is it worth > the effort? Then `temp-buffer-resize-mode' is not suitable for Dired and other similar packages (Proced, VC). When `temp-buffer-resize-mode' is disabled, `dired-mark-pop-up' works correctly for a large list of files because it doesn't steal space from other windows. Its only drawback currently is that it doesn't call `fit-window-to-buffer' for a small number of files. So maybe a more suitable name would be `temp-buffer-shrink-to-fit-mode' or some another name like that. What is essential is that it shouldn't steal space from other windows, but should give away its empty space to the original Dired window (as `fit-window-to-buffer' does in `dired-pop-to-buffer'). This was the original behavior of this feature in Dired. >> I also tried a new action `display-buffer-at-bottom', and it doesn't >> seem quite right yet. With the same configuration (`C-x 3 C-x 2'), >> and two marked files it displays a large almost empty window with just >> two lines. `temp-buffer-resize-mode' helps to narrow it, but I still wonder >> why this window is not frame'e full-width? > > I can add that if you want. I suppose that your initial configuration > was that of >= 2 side-by-side windows at the bottom of the frame? Yes, 2 side-by-side windows at the bottom of the frame. >> I mean the idea was to display >> a list of files near the minibuffer prompt of the left side of the frame, >> but this list is displayed on the right side of the frame. > > Aha. So shall I split/reuse the left bottom window? Or shall I split > the root window immediately? If now is possible to split the root window immediately, then maybe it would be better to try doing so. > The question is whether we want one general setting to handle this. I > intend to use this for `proced-with-processes-buffer' and vc-... buffers > too - adding a separate variable like `dired-shrink-to-fit' for each of > these seems some kind of proliferation. Personally, I'd prefer to > declare `dired-shrink-to-fit' obsolete. Then a new function with a name like `with-temp-buffer-window-pop-up' might be necessary to use it in Dired, Proced, VC that will work like `dired-pop-to-buffer' does when `dired-shrink-to-fit' has its default value t. Please note also that it has this comment: (defvar dired-shrink-to-fit t ;; I see no reason ever to make this nil -- rms. So `dired-shrink-to-fit' could be declared obsolete with functions acting like its value is t. > Note that I have added an option `temp-buffer-resize-regexps' which can > be used to turn off resizing in selected buffers. I could invert the > meaning of this or do something different. Any ideas? You just unified a lot of scattered options (`special-display-regexps', `special-display-buffer-names') to one option `display-buffer-alist', but now reversed the direction of development by adding a new specific `temp-buffer-resize-regexps' ;-) When following the initial design, `display-buffer-alist' should be able to do the same with a corresponding action or property without need to add a new variable. Is this possible to do with the current implementation?