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: Wed, 07 Jan 2009 14:09:35 +0200 Organization: JURTA Message-ID: <87d4ezuw6w.fsf@jurta.org> References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> <4963A229.1030609@gmx.at> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> Reply-To: Juri Linkov , 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 1231333502 21220 80.91.229.12 (7 Jan 2009 13:05:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2009 13:05:02 +0000 (UTC) Cc: 1806@emacsbugs.donarmstrong.com, Roland Winkler To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 07 14:06:12 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 1LKY5t-0004HW-Qk for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 14:05:20 +0100 Original-Received: from localhost ([127.0.0.1]:56170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKY4c-0002Go-D4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 08:03:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKY4I-000290-1d for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 08:03:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKY4F-00028X-Dl for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 08:03:29 -0500 Original-Received: from [199.232.76.173] (port=38612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKY4F-00028U-AG for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 08:03:27 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:41189) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKY4E-0001Hd-J6 for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 08:03:26 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07D3OtY022359; Wed, 7 Jan 2009 05:03:24 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n07D05PD021322; Wed, 7 Jan 2009 05:00:05 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Juri Linkov Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 13:00: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.123133265019848 (code B ref 1806); Wed, 07 Jan 2009 13:00:05 +0000 Original-Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 12:50:50 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07Cok3g019841 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 04:50:47 -0800 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKXrx-000CO8-0U; Wed, 07 Jan 2009 14:50:45 +0200 In-Reply-To: <496483A8.8010805@gmx.at> (martin rudalics's message of "Wed, 07 Jan 2009 11:27:52 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) X-Scanner-Signature: b72b012eade34d4806fecc225a7d7ed8 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6672 [Jan 07 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Wed, 07 Jan 2009 08:03:29 -0500 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:23872 Archived-At: >> I can't image a situation when someone will want to display a narrow >> window on a full-height side window. At least I think currently we should >> restore the old behavior when these commands displayed a narrow window >> below the original window instead of a side window. > > I did this for `dired-pop-to-buffer'. Thanks, it now works for the one-window configuration. However, when windows are already split horizontally, it still doesn't work like it always worked by displaying a small window below. As you can see in the code removed from `dired-pop-to-buffer' it used to call `split-window' explicitly: (setq w2 (split-window window (max window-min-height (- (window-height window) (1+ (max window-min-height target-lines)))))) We need a new special function in window.el that will do something similar. >> I think a general rule of thumb for finding all such cases should be the >> following: when there is a call to `fit-window-to-buffer' after calling >> `pop-to-buffer' then split windows vertically because otherwise >> `fit-window-to-buffer' makes no sense since it adjusts the window height >> and can't do this on a full-height horizontally split window. > > Good suggestion. I found the following candidates: > > `Electric-pop-up-window', `ibuffer-confirm-operation-on', > `disabled-command-function', `proced-send-signal', > `fancy-startup-screen', `display-time-world', `widget-choose'. > > Can someone comment on these? `proced-send-signal' is a recent change: 2009-01-03 Roland Winkler * proced.el (proced-send-signal): Use fit-window-to-buffer instead of dired-pop-to-buffer. Roland, maybe we need a general function for both Proced and Dired? > We might also have to consider windows affected by > `temp-buffer-resize-mode'. I'll leave it to Carsten to figure out > what's best for `org-mode'. > > As for `calendar' I share Stefan's POV ... Sorry, as a user of a wide-screen configuration I can't use such layout. Every time I run `calendar' I need manually fix the layout by typing something like `C-x o C-x 2 C-x o C-x left C-x -'. This is a real hassle! For users who don't want a silly tall mostly empty 70-line window we should have an option like `dired-shrink-to-fit' to always show a 7-line window. This layout also works well with the diary buffer: +------------+------------+ | | | | | | | diary | | | | | | | | | | | | | | | | | +------------+ | | | | | calendar | | | | | +------------+------------+ Please see the code in calendar.el that creates such standard layout for non-wide-screen configurations (i.e. when there is no right window). I think we should keep exactly the same logic for wide-screen configurations, i.e. treating the creation of such small low windows as if there is no existing side window. -- Juri Linkov http://www.jurta.org/emacs/