From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 15:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.123125587920589 (code B ref -1); Tue, 06 Jan 2009 15:40:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 15:31:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n06FVFoS020582 for ; Tue, 6 Jan 2009 07:31:16 -0800 Received: from mx10.gnu.org ([199.232.76.166]:44002) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKDsa-0004TZ-DK for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:30:04 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKDte-0001eT-Vv for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:31:14 -0500 Received: from relay03.kiev.sovam.com ([62.64.120.201]:53363) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKDte-0001e9-KR for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:31:10 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKDtc-000Crn-AT for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:31:08 +0200 From: Juri Linkov To: emacs-pretest-bug@gnu.org Organization: JURTA Date: Tue, 06 Jan 2009 17:29:55 +0200 Message-ID: <87r63gzcap.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 233cb89e4cdd9c68f6fe52a505261b56 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6665 [Jan 06 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: Genre and OS details not recognized. After 2008-12-11 change to window.el and dired.el that fixed the bug #1488, I have difficulties using dired. Before this change, running a dired operation on many files displayed a pop-up window *below* the dired buffer and immediately *above* the minibuffer. This is the most convenient place to display a list of file names, because it is near the minibuffer where the user types more input for the command (a shell command or a directory to copy files to). But now this list of files is displayed somewhere else - on the top of the side window. Thus now this list is as far for minibuffer as possible. This is because `dired-pop-to-buffer' doesn't call `split-window' anymore that used to split windows vertically even on a wide-screen display. This is the same problem as I reported in http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236 i.e. we need a special option to split windows vertically where necessary. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 17:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123126327219311 (code B ref 1806); Tue, 06 Jan 2009 17:40:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 17:34:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n06HYRT0019305 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 09:34:29 -0800 Received: (qmail invoked by alias); 06 Jan 2009 17:34:21 -0000 Received: from 88-117-42-126.adsl.highway.telekom.at (EHLO [88.117.42.126]) [88.117.42.126] by mail.gmx.net (mp067) with SMTP; 06 Jan 2009 18:34:21 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/TcBlpYJbTeLfr4uIfdqW9CWSMU8e0LL1OEa7Xzb qdxOAksEzx8OnL Message-ID: <496395F6.8050409@gmx.at> Date: Tue, 06 Jan 2009 18:33:42 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> In-Reply-To: <87r63gzcap.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 > But now this list of files is displayed somewhere else - on the top of the > side window. Thus now this list is as far for minibuffer as possible. > This is because `dired-pop-to-buffer' doesn't call `split-window' anymore > that used to split windows vertically even on a wide-screen display. > > This is the same problem as I reported in > http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236 > i.e. we need a special option to split windows vertically > where necessary. But that's what `split-width-threshold' is meant for. Does `dired-pop-to-buffer' DTRT when you set this to nil? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 18:05:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123126459725421 (code B ref 1806); Tue, 06 Jan 2009 18:05:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 17:56:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n06HuTox025415 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 09:56:30 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKGAF-000Ges-Ik; Tue, 06 Jan 2009 19:56:27 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> Date: Tue, 06 Jan 2009 19:54:07 +0200 In-Reply-To: <496395F6.8050409@gmx.at> (martin rudalics's message of "Tue, 06 Jan 2009 18:33:42 +0100") Message-ID: <87prj0uxq8.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 367251710ae6d8069d2a2bb66b314d03 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6669 [Jan 06 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 >> But now this list of files is displayed somewhere else - on the top of the >> side window. Thus now this list is as far for minibuffer as possible. >> This is because `dired-pop-to-buffer' doesn't call `split-window' anymore >> that used to split windows vertically even on a wide-screen display. >> >> This is the same problem as I reported in >> http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236 >> i.e. we need a special option to split windows vertically >> where necessary. > > But that's what `split-width-threshold' is meant for. Does > `dired-pop-to-buffer' DTRT when you set this to nil? Yes, it works perfectly for Dired when `split-width-threshold' is nil. But the problem is that I prefer a wide-screen configuration with horizontally split windows, so I can't set `split-width-threshold' to nil. There are a few exceptions where obeying non-nil `split-width-threshold' is not desirable. One exception is displaying a list of files in Dired, and another is displaying the Calendar window. Maybe there are a few of others. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 18:35:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12312663991113 (code B ref 1806); Tue, 06 Jan 2009 18:35:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 18:26:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n06IQZRi001107 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 10:26:37 -0800 Received: (qmail invoked by alias); 06 Jan 2009 18:26:29 -0000 Received: from 88-117-42-126.adsl.highway.telekom.at (EHLO [88.117.42.126]) [88.117.42.126] by mail.gmx.net (mp002) with SMTP; 06 Jan 2009 19:26:29 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18tqQRa+Fkteb2Xq2Am6dyoqlMtBYa5Iuesd0d/Zq Dq8JUm+Row9Aix Message-ID: <4963A229.1030609@gmx.at> Date: Tue, 06 Jan 2009 19:25:45 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> In-Reply-To: <87prj0uxq8.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 > Yes, it works perfectly for Dired when `split-width-threshold' is nil. Fine. > But the problem is that I prefer a wide-screen configuration with > horizontally split windows, so I can't set `split-width-threshold' to nil. > > There are a few exceptions where obeying non-nil `split-width-threshold' > is not desirable. One exception is displaying a list of files in Dired, > and another is displaying the Calendar window. Maybe there are a few > of others. So the only thing we have to decide is whether we want to hardcode this in `dired-pop-to-buffer' (and for the Calendar window and others) or make it optional. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 21:25:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123127650411201 (code B ref 1806); Tue, 06 Jan 2009 21:25:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 21:15:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n06LF0QZ011061 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 13:15:01 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKJGN-0006br-Pr; Tue, 06 Jan 2009 23:14:59 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> <4963A229.1030609@gmx.at> Date: Tue, 06 Jan 2009 23:09:16 +0200 In-Reply-To: <4963A229.1030609@gmx.at> (martin rudalics's message of "Tue, 06 Jan 2009 19:25:45 +0100") Message-ID: <87aba4qh1b.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 8abf2c83e696415c40c55866f9369f42 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6669 [Jan 06 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 >> There are a few exceptions where obeying non-nil `split-width-threshold' >> is not desirable. One exception is displaying a list of files in Dired, >> and another is displaying the Calendar window. Maybe there are a few >> of others. > > So the only thing we have to decide is whether we want to hardcode this > in `dired-pop-to-buffer' (and for the Calendar window and others) or > make it optional. 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 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. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 22:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123127966225150 (code B ref 1806); Tue, 06 Jan 2009 22:15:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 22:07:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n06M7YU8025144 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 14:07:36 -0800 Received: from alfajor.home (vpn-132-204-232-85.acd.umontreal.ca [132.204.232.85]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n06M8D5a011401; Tue, 6 Jan 2009 17:08:13 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 55EE71C83E; Tue, 6 Jan 2009 17:07:33 -0500 (EST) From: Stefan Monnier To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> Date: Tue, 06 Jan 2009 17:07:33 -0500 In-Reply-To: <87prj0uxq8.fsf@jurta.org> (Juri Linkov's message of "Tue, 06 Jan 2009 19:54:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3183=0 > is not desirable. One exception is displaying a list of files in Dired, > and another is displaying the Calendar window. Maybe there are a few > of others. For buffers showing information directly linked to the minibuffer (such as Dired's file list, and maybe also *Completions*), it might make sense to make an exception, indeed. OTOH, I don't understand why you feel the same way for the Calendar window. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 23:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123128459912936 (code B ref 1806); Tue, 06 Jan 2009 23:35:02 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Jan 2009 23:29:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n06NTt5I012930 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 15:29:57 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKLMx-000FbM-3Z; Wed, 07 Jan 2009 01:29:55 +0200 From: Juri Linkov To: Stefan Monnier Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> Date: Wed, 07 Jan 2009 01:27:38 +0200 In-Reply-To: (Stefan Monnier's message of "Tue, 06 Jan 2009 17:07:33 -0500") Message-ID: <87iqosj9qt.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 068dd79c68aafbc760c35e97c5d420ed X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] 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 >> is not desirable. One exception is displaying a list of files in Dired, >> and another is displaying the Calendar window. Maybe there are a few >> of others. > > For buffers showing information directly linked to the minibuffer (such > as Dired's file list, and maybe also *Completions*), it might make sense > to make an exception, indeed. > OTOH, I don't understand why you feel the same way for the Calendar window. The Calendar window has a fixed height of 7 lines, and when `split-width-threshold' is nil or the current frame is not wide, it creates a nice small window with the height exactly fit into these 7 lines. But Calendar in a horizontally split window is currently very ugly: there is small text part at the beginning of the window with almost 70 empty lines below. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 04:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123130220521006 (code B ref 1806); Wed, 07 Jan 2009 04:30:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 04:23:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n074NL2j020999 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 20:23:23 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAC+9Y0nO+JnM/2dsb2JhbACBbM1vhXWBaQ X-IronPort-AV: E=Sophos;i="4.37,223,1231131600"; d="scan'208";a="31908313" Received: from 206-248-153-204.dsl.teksavvy.com (HELO ceviche.home) ([206.248.153.204]) by ironport2-out.teksavvy.com with ESMTP; 06 Jan 2009 23:23:15 -0500 Received: by ceviche.home (Postfix, from userid 20848) id AC54E7020E; Tue, 6 Jan 2009 23:23:14 -0500 (EST) From: Stefan Monnier To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> <87iqosj9qt.fsf@jurta.org> Date: Tue, 06 Jan 2009 23:23:14 -0500 In-Reply-To: <87iqosj9qt.fsf@jurta.org> (Juri Linkov's message of "Wed, 07 Jan 2009 01:27:38 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > But Calendar in a horizontally split window is currently very ugly: > there is small text part at the beginning of the window with almost > 70 empty lines below. And if the frame is wide and you set split-width-threshold to nil you get a silly window with only 75 columns used and the rest is empty. Looks just as ugly to me. The advantage of the "side window" layout is that when I then pop up the diary buffer (as I always end up doing), it makes good use of those 70 lines, whereas with your layout, the diary buffer doesn't make use of those extra columns. I'm not saying you're wrong, but just that this is not as clear cut as the "dired files list". Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 10:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123132412715605 (code B ref 1806); Wed, 07 Jan 2009 10:35:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 10:28:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n07ASdh6015599 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 02:28:40 -0800 Received: (qmail invoked by alias); 07 Jan 2009 10:28:33 -0000 Received: from 62-47-36-99.adsl.highway.telekom.at (EHLO [62.47.36.99]) [62.47.36.99] by mail.gmx.net (mp054) with SMTP; 07 Jan 2009 11:28:33 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/vjLZJpNbvOCG0cZPbsjgDYFi3AumOnON/XWCWEm nMQQ/gM+r7HKD/ Message-ID: <496483A8.8010805@gmx.at> Date: Wed, 07 Jan 2009 11:27:52 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org, Carsten Dominik References: <87r63gzcap.fsf@jurta.org> <496395F6.8050409@gmx.at> <87prj0uxq8.fsf@jurta.org> <4963A229.1030609@gmx.at> <87aba4qh1b.fsf@jurta.org> In-Reply-To: <87aba4qh1b.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 > 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'. > 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? 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 ... martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: run command split the window type question......... Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 10:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123132484219197 (code B ref 1806); Wed, 07 Jan 2009 10:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 10:40:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n07Aeb5S019191 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 02:40:39 -0800 Received: (qmail invoked by alias); 07 Jan 2009 10:40:32 -0000 Received: from 62-47-44-44.adsl.highway.telekom.at (EHLO [62.47.44.44]) [62.47.44.44] by mail.gmx.net (mp021) with SMTP; 07 Jan 2009 11:40:32 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18UTiEJ/9YUGjSnrgZ0pMVBR4xevpUtOQjKxlCIdX 6Kj6pjY6QqvFau Message-ID: <49648677.1040606@gmx.at> Date: Wed, 07 Jan 2009 11:39:51 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: 1806@debbugs.gnu.org CC: 8863824@gmail.com References: 0ade9f4a-af7a-4aca-b57a-dc166366db5b@i20g2000prf.googlegroups.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8 > when i run the "compile" command, emacs auto split the window. > some times right/left type, some times top/down type. > i want default : top/down type. > who can help me, please, my english is very poor ,but i havn't another > idea.. Yet another candidate from help-gnu-emacs. Welcome to the club ... martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 13:00:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123133265019848 (code B ref 1806); Wed, 07 Jan 2009 13:00:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 12:50:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org, Roland Winkler Organization: JURTA 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> Date: Wed, 07 Jan 2009 14:09:35 +0200 In-Reply-To: <496483A8.8010805@gmx.at> (martin rudalics's message of "Wed, 07 Jan 2009 11:27:52 +0100") Message-ID: <87d4ezuw6w.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 >> 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/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 15:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123134250228776 (code B ref 1806); Wed, 07 Jan 2009 15:40:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 15:35:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n07FYwtV028736 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 07:35:00 -0800 Received: (qmail invoked by alias); 07 Jan 2009 15:34:53 -0000 Received: from 62-47-38-92.adsl.highway.telekom.at (EHLO [62.47.38.92]) [62.47.38.92] by mail.gmx.net (mp069) with SMTP; 07 Jan 2009 16:34:53 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX194KCBm4Gl4fPndNl+xdZcQcwY4w2aC7iLNo5gPk3 X0TG5QKrfzbUH2 Message-ID: <4964CB72.1090605@gmx.at> Date: Wed, 07 Jan 2009 16:34:10 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> In-Reply-To: <87d4ezuw6w.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 > 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)))))) Usually this worked correctly due to the fact that directory buffers were sufficiently high. But for `pop-up-frames' non-nil addicts this was not necessarily the right behavior. Anyway, I suppose you mean something like (defun dired-pop-to-buffer (buf) (let* ((split-height-threshold 8) split-width-threshold (buffer (get-buffer-create buf)) (window (window--try-to-split-window (selected-window)))) (if window (progn (select-window window) (set-window-buffer window buffer)) (pop-to-buffer buffer)) (when dired-shrink-to-fit (fit-window-to-buffer nil nil 1)))) > 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. Would the above code handle that? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 18:05:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123135098632567 (code B ref 1806); Wed, 07 Jan 2009 18:05:09 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 17:56:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07HuM3f032552 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 09:56:23 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKcdm-000Clo-7h; Wed, 07 Jan 2009 19:56:26 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> Date: Wed, 07 Jan 2009 19:47:59 +0200 In-Reply-To: <4964CB72.1090605@gmx.at> (martin rudalics's message of "Wed, 07 Jan 2009 16:34:10 +0100") Message-ID: <87aba3qb5g.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: efe3bc1504fa577d936f03857ce6b673 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] 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 > Usually this worked correctly due to the fact that directory buffers > were sufficiently high. But for `pop-up-frames' non-nil addicts this > was not necessarily the right behavior. > > Anyway, I suppose you mean something like > > (defun dired-pop-to-buffer (buf) > (let* ((split-height-threshold 8) > split-width-threshold > (buffer (get-buffer-create buf)) > (window (window--try-to-split-window (selected-window)))) > (if window > (progn > (select-window window) > (set-window-buffer window buffer)) > (pop-to-buffer buffer)) > (when dired-shrink-to-fit > (fit-window-to-buffer nil nil 1)))) Thank you, this works almost ideally. The only problem I've encountered is that sometimes it resizes existing windows: +------------+------------+ +------------+------------+ | | | | | | | | | | | | | dired | other2 | | dired | other2 | | | | | | | | | | +------------+ | | | | | file list | | | | | ===> +------------+ | +------------+ | | | | | | | | | | | other1 | | | other1 | | | | | | | | | | | | | | +------------+------------+ +------------+------------+ Please notice how the upper border of the lower window (other1) was moved up. I think it should keep the existing configuration and create a new window at the cost of space from the original dired buffer like this: +------------+------------+ +------------+------------+ | | | | | | | | | | | | | dired | other | | dired | other | | | | | | | | | | | | | | | | +------------+ | | | | | file list | | +------------+ | ===> +------------+ | | | | | | | | other | | | other | | | | | | | | | | | | | | +------------+------------+ +------------+------------+ As I can see currently `fit-window-to-buffer' always takes space from the bottom window, but we need it from the top window. >> 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. > > Would the above code handle that? I believe it would handle these cases. Maybe it is possible to create a single function e.g. `pop-to-buffer-below' that will display a new window below from the current window taking its space. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: run command split the window type question......... Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 18:05:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123135098732572 (code B ref 1806); Wed, 07 Jan 2009 18:05:11 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 17:56:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07HuObF032555 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 09:56:25 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKcdn-000Cm7-Q5; Wed, 07 Jan 2009 19:56:28 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org, 8863824@gmail.com Organization: JURTA References: <49648677.1040606@gmx.at> Date: Wed, 07 Jan 2009 19:52:56 +0200 In-Reply-To: <49648677.1040606@gmx.at> (martin rudalics's message of "Wed, 07 Jan 2009 11:39:51 +0100") Message-ID: <87ljtnowc7.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: b36477657b07eb27dc67b07df918f397 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] 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 >> when i run the "compile" command, emacs auto split the window. >> some times right/left type, some times top/down type. >> i want default : top/down type. >> who can help me, please, my english is very poor ,but i havn't another >> idea.. > > Yet another candidate from help-gnu-emacs. Welcome to the club ... This indicates that we may need adding a new option like `same-window-regexps' with a list of regexps saying which buffers should use which window splitting style. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 20:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123135852432189 (code B ref 1806); Wed, 07 Jan 2009 20:10:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Jan 2009 20:02:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n07K1vtO032175 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 12:02:01 -0800 Received: (qmail invoked by alias); 07 Jan 2009 20:01:51 -0000 Received: from 62-47-44-119.adsl.highway.telekom.at (EHLO [62.47.44.119]) [62.47.44.119] by mail.gmx.net (mp071) with SMTP; 07 Jan 2009 21:01:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/hr5gHGt/hNzKPfkE4KVpNgFb3Ha7hm+oH369HDp oLFqWxwhDedjhL Message-ID: <496509D3.7070107@gmx.at> Date: Wed, 07 Jan 2009 21:00:19 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> In-Reply-To: <87aba3qb5g.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 > As I can see currently `fit-window-to-buffer' always takes space > from the bottom window, but we need it from the top window. Not really. `fit-window-to-buffer' uses `enlarge-window' which is our idea of Robin Hood - stealing from the large, giving to the small. An impractical solution is to make all other windows fixed-height and do the fit. This will almost certainly fail since deleting the window may give its space to _any_ of its siblings. A more practical solution would be to implement something like the following: When a new window is created, remember the OLD _and_ the NEW window configuration in the window's parameters. When the window is eventually deleted and the actual configuration "sufficiently" resembles the NEW configuration, restore the OLD configuration. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: run command split the window type question......... Reply-To: soldier <8863824@gmail.com>, 1806@debbugs.gnu.org Resent-From: soldier <8863824@gmail.com> Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 03:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12313832676302 (code B ref 1806); Thu, 08 Jan 2009 03:00:02 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 02:54:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.0 required=4.0 tests=FROM_STARTS_WITH_NUMS, HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n082sKAX006296 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 18:54:21 -0800 Received: by rv-out-0506.google.com with SMTP id k40so8180672rvb.1 for <1806@emacsbugs.donarmstrong.com>; Wed, 07 Jan 2009 18:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=vcB7mcXHDF20nkPJq1haxPohAznBjOYj3n72DP84SKk=; b=oPJiqFvvuyFswpnuwD+f5HFoEtliFZA+IG4Atqewn8s37joerA2zHuAkEG2QZpCO3m GIAoPkU1JFsvYeFfBG7tLhrDNCrGBJ6nsz5OEIiuEgQdelzIHKxwijebyOyH6r1vxhTX 0nOCRS17BMlmzXL1oRi/lM85Piu4KofPmuWUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jn3dFY/A5166Y7pMS/nxcVDpNySjMWmCcFv7/eX2Eu8dt0379nMMmqI1fphhsGKL8S Eg+B7gL6EdQU4DiANM1/+zmVtN8Ku8mG5sx5pqMmhuhcxAUyBfemnbZgIR3p/QPjJDjE maZyhGbYiZwFRaxYroGTpDdXcIaahjDcvoTM4= Received: by 10.142.78.8 with SMTP id a8mr9947461wfb.348.1231383259603; Wed, 07 Jan 2009 18:54:19 -0800 (PST) Received: by 10.143.30.18 with HTTP; Wed, 7 Jan 2009 18:54:19 -0800 (PST) Message-ID: <958f634e0901071854l81f9173sbdfd1efbecd6b72f@mail.gmail.com> Date: Thu, 8 Jan 2009 10:54:19 +0800 From: soldier <8863824@gmail.com> To: "Juri Linkov" Cc: "martin rudalics" , 1806@debbugs.gnu.org In-Reply-To: <87ljtnowc7.fsf@jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49648677.1040606@gmx.at> <87ljtnowc7.fsf@jurta.org> thank you very much. i hope have a global option to set the auto split style of all. and now can do it? 2009/1/8 Juri Linkov : >>> when i run the "compile" command, emacs auto split the window. >>> some times right/left type, some times top/down type. >>> i want default : top/down type. >>> who can help me, please, my english is very poor ,but i havn't another >>> idea.. >> >> Yet another candidate from help-gnu-emacs. Welcome to the club ... > > This indicates that we may need adding a new option like > `same-window-regexps' with a list of regexps saying which > buffers should use which window splitting style. > > -- > Juri Linkov > http://www.jurta.org/emacs/ > From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 07:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123140065414118 (code B ref 1806); Thu, 08 Jan 2009 07:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 07:44:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MIXEDBDN,MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n087i5mQ014110 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 23:44:06 -0800 Received: (qmail invoked by alias); 08 Jan 2009 07:43:58 -0000 Received: from 62-47-56-228.adsl.highway.telekom.at (EHLO [62.47.56.228]) [62.47.56.228] by mail.gmx.net (mp058) with SMTP; 08 Jan 2009 08:43:58 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18Cr9cHNTwCi0u+6RJrOqfDGIqcfI9pmFQNsImAlI rjEPh+WEgYxyxW Message-ID: <4965AE6B.6070802@gmx.at> Date: Thu, 08 Jan 2009 08:42:35 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> In-Reply-To: <87aba3qb5g.fsf@jurta.org> Content-Type: multipart/mixed; boundary="------------070905070108060508040600" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001,0.54 This is a multi-part message in MIME format. --------------070905070108060508040600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > As I can see currently `fit-window-to-buffer' always takes space > from the bottom window, but we need it from the top window. Looking at this again, I believe what you want is to invert the order of stealing and giving as in the attached patch. Might have side-effects elsewhere. martin --------------070905070108060508040600 Content-Type: text/plain; name="window.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="window.c.diff" Index: window.c =================================================================== RCS file: /sources/emacs/emacs/src/window.c,v retrieving revision 1.638 diff -c -r1.638 window.c *** window.c 8 Jan 2009 03:16:08 -0000 1.638 --- window.c 8 Jan 2009 07:21:10 -0000 *************** *** 4125,4171 **** while (delta != 0 && (!NILP (next) || !NILP (prev))) { ! if (! NILP (next)) { ! int this_one = ((*sizefun) (next) ! - window_min_size (XWINDOW (next), horiz_flag, 0, 0, &fixed_p)); if (!fixed_p) { if (this_one > delta) this_one = delta; ! (*setsizefun) (next, (*sizefun) (next) - this_one, 0); (*setsizefun) (window, XINT (*sizep) + this_one, 0); delta -= this_one; } ! next = XWINDOW (next)->next; } if (delta == 0) break; ! if (! NILP (prev)) { ! int this_one = ((*sizefun) (prev) ! - window_min_size (XWINDOW (prev), horiz_flag, 0, 0, &fixed_p)); if (!fixed_p) { if (this_one > delta) this_one = delta; ! first_affected = prev; ! ! (*setsizefun) (prev, (*sizefun) (prev) - this_one, 0); (*setsizefun) (window, XINT (*sizep) + this_one, 0); delta -= this_one; } ! prev = XWINDOW (prev)->prev; } } --- 4125,4171 ---- while (delta != 0 && (!NILP (next) || !NILP (prev))) { ! if (! NILP (prev)) { ! int this_one = ((*sizefun) (prev) ! - window_min_size (XWINDOW (prev), horiz_flag, 0, 0, &fixed_p)); if (!fixed_p) { if (this_one > delta) this_one = delta; ! first_affected = prev; ! ! (*setsizefun) (prev, (*sizefun) (prev) - this_one, 0); (*setsizefun) (window, XINT (*sizep) + this_one, 0); delta -= this_one; } ! prev = XWINDOW (prev)->prev; } if (delta == 0) break; ! if (! NILP (next)) { ! int this_one = ((*sizefun) (next) ! - window_min_size (XWINDOW (next), horiz_flag, 0, 0, &fixed_p)); if (!fixed_p) { if (this_one > delta) this_one = delta; ! (*setsizefun) (next, (*sizefun) (next) - this_one, 0); (*setsizefun) (window, XINT (*sizep) + this_one, 0); delta -= this_one; } ! next = XWINDOW (next)->next; } } --------------070905070108060508040600-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: run command split the window type question......... Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 08:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123140119016531 (code B ref 1806); Thu, 08 Jan 2009 08:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 07:53:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n087r6YY016525 for <1806@emacsbugs.donarmstrong.com>; Wed, 7 Jan 2009 23:53:07 -0800 Received: (qmail invoked by alias); 08 Jan 2009 07:53:00 -0000 Received: from 62-47-36-11.adsl.highway.telekom.at (EHLO [62.47.36.11]) [62.47.36.11] by mail.gmx.net (mp001) with SMTP; 08 Jan 2009 08:53:00 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX183tXgla8M3lZzHJuQqJOBltQU78KnDKQihARIDoy AlPvxRZSEufxBz Message-ID: <4965B0B1.9010101@gmx.at> Date: Thu, 08 Jan 2009 08:52:17 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: soldier <8863824@gmail.com> CC: Juri Linkov , 1806@debbugs.gnu.org References: <49648677.1040606@gmx.at> <87ljtnowc7.fsf@jurta.org> <958f634e0901071854l81f9173sbdfd1efbecd6b72f@mail.gmail.com> In-Reply-To: <958f634e0901071854l81f9173sbdfd1efbecd6b72f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 > i hope have a global option to set the auto split style of all. > and now can do it? When you set `split-width-threshold' to nil, Emacs won't automatically split windows horizontally. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Carsten Dominik , 1806@debbugs.gnu.org Resent-From: Carsten Dominik Original-Sender: Carsten Dominik Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 12:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123141553212433 (code B ref 1806); Thu, 08 Jan 2009 12:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 11:52:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER,MULTALT, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n08Bq7Wp012426 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 03:52:09 -0800 Received: by nf-out-0910.google.com with SMTP id 30so1003829nfu.31 for <1806@emacsbugs.donarmstrong.com>; Thu, 08 Jan 2009 03:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=54GprMFKBPr5BXquSR7xnjvyIu9oG6JL3LYVUFh0hX8=; b=oQ2KH0vW2301q1G5MSBWOW6/N2b55jt6Bbilyq/NQdOFCKs6yJ49kI6GsmIhzjTBWM Uf56OAuoE9lFgcWB1muD8jU9iRBS6WADy2dBOdQYhwBo1SklH4j5lJa6LvO8pGJpVx06 /qIgZIyPcVJU3f6pIdrOAg9rkhRnVBD2MV/40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type:mime-version :subject:date:references:x-mailer; b=vWysEXQ9bhx7pAvVOg8trEL7ycqkPNDRM3j0s/RvkJwLQsN6h/7bt6fH2dHPzDaLEZ agedwFmDppNrtOng9i0gagBDI4s2i3YfX7A9gRde8/Ey46A6D2Lh4JgXahui8dHTp0qt 2CpZ+ZJmR91YfDMalJfQf+LhMe6rSVcZMcO+Y= Received: by 10.67.119.20 with SMTP id w20mr14455220ugm.78.1231415527143; Thu, 08 Jan 2009 03:52:07 -0800 (PST) Received: from nb-dominik2.science.uva.nl (nb-dominik2.science.uva.nl [146.50.22.167]) by mx.google.com with ESMTPS id 39sm23885100ugb.43.2009.01.08.03.52.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Jan 2009 03:52:06 -0800 (PST) Sender: Carsten Dominik Cc: Juri Linkov , 1806@debbugs.gnu.org, Carsten Dominik Message-Id: From: Carsten Dominik To: martin rudalics In-Reply-To: <496483A8.8010805@gmx.at> Content-Type: multipart/alternative; boundary=Apple-Mail-7--294745460 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 8 Jan 2009 12:52:04 +0100 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> X-Mailer: Apple Mail (2.929.2) --Apple-Mail-7--294745460 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jan 7, 2009, at 11:27 AM, martin rudalics wrote: > > 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'. > > > 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? 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'. Hi Martin, org-mode already protects itself against this possibility, I think: Here is my code: (defun org-fit-window-to-buffer (&optional window max-height min-height shrink-only) "Fit WINDOW to the buffer, but only if it is not a side-by-side window. WINDOW defaults to the selected window. MAX-HEIGHT and MIN-HEIGHT are passed through to `fit-window-to-buffer'. If SHRINK-ONLY is set, call `shrink-window-if-larger-than-buffer' instead, the hight limit are ignored in this case." (cond ((> (frame-width) (window-width window)) ;; do nothing if another window would suffer ) ((and (fboundp 'fit-window-to-buffer) (not shrink-only)) (fit-window-to-buffer window max-height min-height)) ((fboundp 'shrink-window-if-larger-than-buffer) (shrink-window-if-larger-than-buffer window))) (or window (selected-window))) If the current window is not the full frame width, I do not adjust its size because it would shink other windows along with it. - Carsten > > > As for `calendar' I share Stefan's POV ... > > martin --Apple-Mail-7--294745460 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jan 7, 2009, = at 11:27 AM, martin rudalics wrote:

> 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'.

> 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?  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'.

Hi = Martin,

org-mode already protects itself = against this possibility, I think:
Here is my = code:

(defun org-fit-window-to-buffer = (&optional window max-height min-height
=   shrink-only)
  "Fit = WINDOW to the buffer, but only if it is not a side-by-side = window.
WINDOW defaults to the selected window.  MAX-HEIGHT and = MIN-HEIGHT are
passed through to `fit-window-to-buffer'. =  If SHRINK-ONLY is set, call
`shrink-window-if-larger-than-buffer' instead, the hight limit = are
ignored in this case."
  (cond = ((> (frame-width) (window-width window))
= = ;; do nothing if another window would suffer
= = )
((and (fboundp = 'fit-window-to-buffer) (not shrink-only))
= = (fit-window-to-buffer window max-height = min-height))
((fboundp = 'shrink-window-if-larger-than-buffer)
= = (shrink-window-if-larger-than-buffer window)))
  (or = window (selected-window)))


If the current = window is not the full frame width, I do not adjust its size because it = would shink other windows along with it.

- = Carsten



<= blockquote type=3D"cite">


As for `calendar' I share Stefan's = POV ...

martin

= --Apple-Mail-7--294745460-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: "Roland Winkler" , 1806@debbugs.gnu.org Resent-From: "Roland Winkler" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 14:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123142509921182 (code B ref 1806); Thu, 08 Jan 2009 14:40:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 14:31:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from tfkpsv.physik.uni-erlangen.de (tfkpsv.physik.uni-erlangen.de [131.188.164.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n08EVVa1021176 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 06:31:33 -0800 Received: from tfkp04.physik.uni-erlangen.de (tfkp04.physik.uni-erlangen.de [131.188.164.204]) by tfkpsv.physik.uni-erlangen.de (Postfix) with ESMTP id 64A8E21FF7; Thu, 8 Jan 2009 15:31:29 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18790.3647.727908.126656@tfkp04.physik.uni-erlangen.de> Date: Thu, 8 Jan 2009 15:31:27 +0100 From: "Roland Winkler" To: Juri Linkov Cc: martin rudalics , 1806@debbugs.gnu.org In-Reply-To: <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> <87d4ezuw6w.fsf@jurta.org> X-Mailer: VM 8.0.9 under Emacs 22.2.1 (i686-pc-linux-gnu) On Wed Jan 7 2009 Juri Linkov wrote: > > 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? When I changed proced to use fit-window-to-buffer, this change was inspired by the changed code of dired-pop-to-buffer. Later I realized that this doesn't always give the old behavior of dired-pop-to-buffer which in my opinion was more appropriate than the new code (but I hadn't found time yet to look into this more carefully). So yes, I agree that probably it would be best to have a function that gives the old behavior which can be used by both dired and proced. And maybe the new function will be useful for other packages, too. Roland From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 19:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123144277631561 (code B ref 1806); Thu, 08 Jan 2009 19:35:02 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 19:26:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n08JQ8Ka031555 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 11:26:12 -0800 Received: (qmail invoked by alias); 08 Jan 2009 19:26:02 -0000 Received: from 62-47-57-3.adsl.highway.telekom.at (EHLO [62.47.57.3]) [62.47.57.3] by mail.gmx.net (mp010) with SMTP; 08 Jan 2009 20:26:02 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+pCOcyMWOpXCc1c8R6tO1xkCTjOB/a+DSzmk49RR 7pdTrANUj2Ezwm Message-ID: <4966531E.3050300@gmx.at> Date: Thu, 08 Jan 2009 20:25:18 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Carsten Dominik CC: Juri Linkov , 1806@debbugs.gnu.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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 > (cond ((> (frame-width) (window-width window)) It might be better to use (not (window-full-width-p window)) here. Comparing `frame-width' and `window-width' is not always reliable. > If the current window is not the full frame width, I do not adjust its > size because it would shink other windows along with it. IIUC you mostly use a (delete-other-windows) (split-window-vertically) (org-switch-to-buffer-other-window ...) paradigm which avoids most of the pitfalls raised by Juri. So I think you are not really bothered by the problems discussed here. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 19:35:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123144279231573 (code B ref 1806); Thu, 08 Jan 2009 19:35:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 19:26:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n08JQRsT031565 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 11:26:29 -0800 Received: (qmail invoked by alias); 08 Jan 2009 19:26:18 -0000 Received: from 62-47-57-3.adsl.highway.telekom.at (EHLO [62.47.57.3]) [62.47.57.3] by mail.gmx.net (mp062) with SMTP; 08 Jan 2009 20:26:18 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+FsD95gS6FZKNJIKK0Iyr6uHBhTW8kgfEJRRc3fK 9idCrdOaaMd2ci Message-ID: <49665326.8060607@gmx.at> Date: Thu, 08 Jan 2009 20:25:26 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org, Juri Linkov 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.72 > I think pop-to-buffer should be extended in the following way: > currently, the only way for pop-to-buffer to indicate "where" to display > the buffer is via the `other-buffer' argument. ... you mean the `other-window' argument ... > This should be > generalized so as to be able to say "preferably in the selected-window" > (to provide basically the behavior of switch-to-buffer), or "preferably > in selected-frame", or "preferably close to the minibuffer". The first > 2 are available *to the user* via the `same-window' and `same-frame' > attribute that they can set in special-display-buffer-names, but they > should also be available to the program (and overridable by the user). But none of these provide the behavior wanted by Juri. He wants to split the selected window which runs counter to the `pop-up-frames' non-nil ideology. So I suppose we need a "preferably splitting the selected window" value which can be overridden by `pop-up-frames'. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 23:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123145602623462 (code B ref 1806); Thu, 08 Jan 2009 23:15:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 23:07:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n08N72ex023454 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 15:07:03 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LL3xs-000IWH-Os; Fri, 09 Jan 2009 01:07:01 +0200 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> Date: Fri, 09 Jan 2009 00:59:17 +0200 In-Reply-To: <49665326.8060607@gmx.at> (martin rudalics's message of "Thu, 08 Jan 2009 20:25:26 +0100") Message-ID: <87skntl95i.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 233cb89e4cdd9c68f6fe52a505261b56 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6681 [Jan 08 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 >> This should be >> generalized so as to be able to say "preferably in the selected-window" >> (to provide basically the behavior of switch-to-buffer), or "preferably >> in selected-frame", or "preferably close to the minibuffer". The first >> 2 are available *to the user* via the `same-window' and `same-frame' >> attribute that they can set in special-display-buffer-names, but they >> should also be available to the program (and overridable by the user). > > But none of these provide the behavior wanted by Juri. He wants to > split the selected window which runs counter to the `pop-up-frames' > non-nil ideology. So I suppose we need a "preferably splitting the > selected window" value which can be overridden by `pop-up-frames'. The preferred location of the window can be expressed by the new parameter proposed by Stefan: in addition to `same-window' and `same-frame' it could also support a parameter like `fit-below' with the meaning of creating a new window below from the current window with calling `fit-window-to-buffer' on it. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 08 Jan 2009 23:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123145602723467 (code B ref 1806); Thu, 08 Jan 2009 23:15:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 8 Jan 2009 23:07:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n08N715I023451 for <1806@emacsbugs.donarmstrong.com>; Thu, 8 Jan 2009 15:07:02 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LL3xr-000EHk-AO; Fri, 09 Jan 2009 01:06:59 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> Date: Fri, 09 Jan 2009 00:55:17 +0200 In-Reply-To: <4965AE6B.6070802@gmx.at> (martin rudalics's message of "Thu, 08 Jan 2009 08:42:35 +0100") Message-ID: <87fxjtmo4z.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 7b6940144bc5d56bdacd12344196c2df X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6681 [Jan 08 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 >> As I can see currently `fit-window-to-buffer' always takes space >> from the bottom window, but we need it from the top window. > > Looking at this again, I believe what you want is to invert the order of > stealing and giving as in the attached patch. Might have side-effects > elsewhere. Maybe a simpler solution is to change `fit-window-to-buffer' so in such configurations when windows are split vertically (the correct treating of horizontally split windows is already provided in dired-pop-to-buffer you sent recently) it will temporarily switch the current window to the upper window and call `enlarge-window' from the upper window, thus resizing the right border. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 09 Jan 2009 09:40:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123149346319555 (code B ref 1806); Fri, 09 Jan 2009 09:40:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 9 Jan 2009 09:31:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n099UxtS019547 for <1806@emacsbugs.donarmstrong.com>; Fri, 9 Jan 2009 01:31:00 -0800 Received: (qmail invoked by alias); 09 Jan 2009 09:30:53 -0000 Received: from 62-47-55-79.adsl.highway.telekom.at (EHLO [62.47.55.79]) [62.47.55.79] by mail.gmx.net (mp056) with SMTP; 09 Jan 2009 10:30:53 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18WXpQSUJcWHvN+/OvP/qCKhxCPd0B2MD79wwKVi/ +q77RGKi6O1B2t Message-ID: <49671922.4080609@gmx.at> Date: Fri, 09 Jan 2009 10:30:10 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> In-Reply-To: <87fxjtmo4z.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 >> Looking at this again, I believe what you want is to invert the order of >> stealing and giving as in the attached patch. Might have side-effects >> elsewhere. > > Maybe a simpler solution The change of `enlarge-window' _is_ simple - only the diff appears complicated. But we'd have to decide whether it's OK to steal from/give to the previous window when enlarging a window. (It makes a difference only when we have at least three windows in a row or column.) > is to change `fit-window-to-buffer' > so in such configurations when windows are split vertically We cannot change `fit-window-to-buffer' - it's used, for example, by `resize-temp-buffer-window', not necessarily connected to splitting windows at all. > (the correct treating of horizontally split windows > is already provided in dired-pop-to-buffer you sent recently) > it will temporarily switch the current window to the upper window > and call `enlarge-window' from the upper window, thus resizing > the right border. We'd have to do this within the function that splits the Dired window. I recently rewrote `fit-window-to-buffer' but still don't understand it completely - in particular the (enlarge-window 1) loop. Within that loop we'd have to continuously switch to the Dired window in order too enlarge it. I'd rather avoid such hairy switches. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 09 Jan 2009 09:40:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123149349019575 (code B ref 1806); Fri, 09 Jan 2009 09:40:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 9 Jan 2009 09:31:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n099VQ6X019567 for <1806@emacsbugs.donarmstrong.com>; Fri, 9 Jan 2009 01:31:28 -0800 Received: (qmail invoked by alias); 09 Jan 2009 09:31:21 -0000 Received: from 62-47-55-79.adsl.highway.telekom.at (EHLO [62.47.55.79]) [62.47.55.79] by mail.gmx.net (mp070) with SMTP; 09 Jan 2009 10:31:21 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/Xg5stHDvXK4Dhx8oWFFsgnSn4Y0dulqbb8rccUs ztpZeIpRxk3tPt Message-ID: <4967193D.3060206@gmx.at> Date: Fri, 09 Jan 2009 10:30:37 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org, Juri Linkov 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 >> But none of these provide the behavior wanted by Juri. He wants to >> split the selected window which runs counter to the `pop-up-frames' >> non-nil ideology. > > `same-frame' provides some of the behavior he wants. If the user who > sets pop-up-frames is disappointed that it doesn't bring up a frame, she > can set her special-display-buffer-name so as to override that > `same-frame' attribute. That's not what I meant. The old `dired-pop-to-buffer' did split the window regardless of what `pop-up-frames' was set to and Juri wants to get the old behavior back. The question is whether we want `pop-up-frames' non-nil override that. Currently, `pop-up-frames' non-nil does bring up a separate frame. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 09 Jan 2009 17:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12315215749331 (code B ref 1806); Fri, 09 Jan 2009 17:25:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 9 Jan 2009 17:19:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n09HJToB009325 for <1806@emacsbugs.donarmstrong.com>; Fri, 9 Jan 2009 09:19:31 -0800 Received: from alfajor.home (vpn-132-204-232-74.acd.umontreal.ca [132.204.232.74]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n09HK7Rw028938; Fri, 9 Jan 2009 12:20:07 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 6C46E1C266; Fri, 9 Jan 2009 12:19:27 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> Date: Fri, 09 Jan 2009 12:19:27 -0500 In-Reply-To: <4967193D.3060206@gmx.at> (martin rudalics's message of "Fri, 09 Jan 2009 10:30:37 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3185=0 >>> But none of these provide the behavior wanted by Juri. He wants to >>> split the selected window which runs counter to the `pop-up-frames' >>> non-nil ideology. >> `same-frame' provides some of the behavior he wants. If the user who >> sets pop-up-frames is disappointed that it doesn't bring up a frame, she >> can set her special-display-buffer-name so as to override that >> `same-frame' attribute. > That's not what I meant. The old `dired-pop-to-buffer' did split the > window regardless of what `pop-up-frames' was set to and Juri wants to > get the old behavior back. The question is whether we want > `pop-up-frames' non-nil override that. Currently, `pop-up-frames' > non-nil does bring up a separate frame. I think either behavior is acceptable as long as it can be overridden by the user (via special-display-buffer-names). Reproducing the previous behavior (of ignoring pop-up-frames) is probably the safer option, and it at least would suit my use-pattern better as well (I do have pop-up-frames set to t but would rather not have a new frame created for those dired-lists unless I explicitly set one up in special-display-buffer-names with a specific geometry). Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 00:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.1231891362649 (code B ref 1806); Wed, 14 Jan 2009 00:10:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 00:02:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0E02cop000643 for <1806@emacsbugs.donarmstrong.com>; Tue, 13 Jan 2009 16:02:40 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LMtDQ-000KVV-Ud; Wed, 14 Jan 2009 02:02:37 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> Date: Wed, 14 Jan 2009 01:46:11 +0200 In-Reply-To: <49671922.4080609@gmx.at> (martin rudalics's message of "Fri, 09 Jan 2009 10:30:10 +0100") Message-ID: <87zlhubw10.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: e35cef5ed21d82303c208435479e4a86 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] 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 >>> Looking at this again, I believe what you want is to invert the order of >>> stealing and giving as in the attached patch. Might have side-effects >>> elsewhere. >> >> Maybe a simpler solution > > The change of `enlarge-window' _is_ simple - only the diff appears > complicated. But we'd have to decide whether it's OK to steal from/give > to the previous window when enlarging a window. (It makes a difference > only when we have at least three windows in a row or column.) I've just looked at the old behavior from the December CVS state, and noticed that it behaved more conveniently than we are currently discussing. It displayed a list of files immediately above the minibuffer. This is convenient because when the minibuffer says: ! on * [5 files]: then a list of these 5 files is very near above, so there is no need to search for this list elsewhere on the current frame. Maybe we should have a special function to display a buffer above the minibuffer (e.g. `pop-to-buffer-above-minibuffer')? -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 14:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123194290224434 (code B ref 1806); Wed, 14 Jan 2009 14:30:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 14:21:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0EELcIa024420 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 06:21:40 -0800 Received: (qmail invoked by alias); 14 Jan 2009 14:21:33 -0000 Received: from 88-117-40-31.adsl.highway.telekom.at (EHLO [88.117.40.31]) [88.117.40.31] by mail.gmx.net (mp032) with SMTP; 14 Jan 2009 15:21:33 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19ZGf0LcF9ZaSmQEtRSJ+ozd950vLLoVIGwe2hhs4 zF9ji+WsSV+ko3 Message-ID: <496DF4B9.3080805@gmx.at> Date: Wed, 14 Jan 2009 15:20:41 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> In-Reply-To: <87zlhubw10.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001 > Maybe we > should have a special function to display a buffer above the minibuffer > (e.g. `pop-to-buffer-above-minibuffer')? But when you have vertically-split windows and the *dired* buffer appears on top of the frame, there may be another window between the *dired* window and the *Marked files* window. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 14:30:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123194292024448 (code B ref 1806); Wed, 14 Jan 2009 14:30:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 14:22:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0EELvZ8024442 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 06:21:58 -0800 Received: (qmail invoked by alias); 14 Jan 2009 14:21:48 -0000 Received: from 88-117-40-31.adsl.highway.telekom.at (EHLO [88.117.40.31]) [88.117.40.31] by mail.gmx.net (mp008) with SMTP; 14 Jan 2009 15:21:48 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+3NOs1C2638NqGTwoy/cBw2ELRuBozFuZX5Wc7pO r22b1e9py8Qu3s Message-ID: <496DF4C7.70800@gmx.at> Date: Wed, 14 Jan 2009 15:20:55 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org, Juri Linkov 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 > I think either behavior is acceptable as long as it can be overridden by > the user (via special-display-buffer-names). Reproducing the previous > behavior (of ignoring pop-up-frames) is probably the safer option, and > it at least would suit my use-pattern better as well (I do have > pop-up-frames set to t but would rather not have a new frame created for > those dired-lists unless I explicitly set one up in > special-display-buffer-names with a specific geometry). Maybe we should have `special-display-popup-frame' handle yet another phony parameter, say 'split-window, making it split the selected window if that is set. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 18:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123195602314356 (code B ref 1806); Wed, 14 Jan 2009 18:10:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 18:00:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0EI0Jwq014103 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 10:00:20 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEADW3bUlMCpxj/2dsb2JhbACBbM1ahW+BdQ X-IronPort-AV: E=Sophos;i="4.37,263,1231131600"; d="scan'208";a="32299273" Received: from 76-10-156-99.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 14 Jan 2009 13:00:13 -0500 Received: by pastel.home (Postfix, from userid 20848) id 0B58B7F41; Wed, 14 Jan 2009 13:00:13 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> Date: Wed, 14 Jan 2009 13:00:13 -0500 In-Reply-To: <496DF4C7.70800@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 15:20:55 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I think either behavior is acceptable as long as it can be overridden by >> the user (via special-display-buffer-names). Reproducing the previous >> behavior (of ignoring pop-up-frames) is probably the safer option, and >> it at least would suit my use-pattern better as well (I do have >> pop-up-frames set to t but would rather not have a new frame created for >> those dired-lists unless I explicitly set one up in >> special-display-buffer-names with a specific geometry). > Maybe we should have `special-display-popup-frame' handle yet another > phony parameter, say 'split-window, making it split the selected window > if that is set. Not sure if `split-window' is really what we want. I thought in this case, we want `near-minibuffer'. But, yes, I basically agree. Note that the parameter should be passed from the code, not from special-display-buffer-names (which is a config variable). Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 18:10:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123195605914670 (code B ref 1806); Wed, 14 Jan 2009 18:10:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 18:00:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0EI0tIV014663 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 10:00:57 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEADW3bUlMCpxj/2dsb2JhbACBbM1ahW+BdQ X-IronPort-AV: E=Sophos;i="4.37,263,1231131600"; d="scan'208";a="32299307" Received: from 76-10-156-99.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 14 Jan 2009 13:00:50 -0500 Received: by pastel.home (Postfix, from userid 20848) id 288BF7F41; Wed, 14 Jan 2009 13:00:50 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> Date: Wed, 14 Jan 2009 13:00:50 -0500 In-Reply-To: <496DF4B9.3080805@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 15:20:41 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Maybe we should have a special function to display a buffer above the >> minibuffer (e.g. `pop-to-buffer-above-minibuffer')? > But when you have vertically-split windows and the *dired* buffer > appears on top of the frame, there may be another window between the > *dired* window and the *Marked files* window. And that's good: the list should be close to the question, not close to the dired buffer. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 21:55:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12319698188572 (code B ref 1806); Wed, 14 Jan 2009 21:55:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 21:50:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0ELoDbe008207 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 13:50:15 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LNDcq-0004uw-3N; Wed, 14 Jan 2009 23:50:12 +0200 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> Date: Wed, 14 Jan 2009 23:28:14 +0200 In-Reply-To: <496DF4B9.3080805@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 15:20:41 +0100") Message-ID: <87sknl7e5d.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: b36477657b07eb27dc67b07df918f397 X-DrWeb-checked: yes >> Maybe we >> should have a special function to display a buffer above the minibuffer >> (e.g. `pop-to-buffer-above-minibuffer')? > > But when you have vertically-split windows and the *dired* buffer > appears on top of the frame, there may be another window between the > *dired* window and the *Marked files* window. The list of files closer to the minibuffer is better than closer to the dired buffer because the minibuffer is the place that the user looks at while typing command's arguments for these files. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 22:05:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12319702049799 (code B ref 1806); Wed, 14 Jan 2009 22:05:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 21:56:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0ELuZTa009789 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 13:56:37 -0800 Received: (qmail invoked by alias); 14 Jan 2009 21:56:29 -0000 Received: from 62-47-53-25.adsl.highway.telekom.at (EHLO [62.47.53.25]) [62.47.53.25] by mail.gmx.net (mp044) with SMTP; 14 Jan 2009 22:56:29 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18SWJMSkEISyLet7bJcrTit98zRqeghnv5szoZNY7 pb/EMbUawFpN8u Message-ID: <496E5F58.7030304@gmx.at> Date: Wed, 14 Jan 2009 22:55:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org, Juri Linkov 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 > And that's good: the list should be close to the question, not close to > the dired buffer. If the dired buffer were not needed while asking the question, dired could temporarily display that list in the dired window itself and switch back to the dired buffer afterwards. But I never use dired. What about putting this in `pop-up-windows'? Possible values are: nil do not allow popping up windows 'this selected window 'below below selected window 'below-split split selected window vertically 'right right of selected window 'right-split split selected window horizontally 'bottom use window near bottom of frame 'bottom-split split window near bottom of frame t allow popping up windows If an application (like dired) sees that this variable is t (the default) it may ask to pop up the window wherever it's most suitable. Otherwise, it has to respect the value chosen by the user. Like (let ((pop-up-windows (if (eq pop-up-windows t) 'bottom-split pop-up-windows))) (display-buffer ...)) martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 22:10:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123197055711018 (code B ref 1806); Wed, 14 Jan 2009 22:10:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 22:02:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0EM2XxW011012 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 14:02:35 -0800 Received: (qmail invoked by alias); 14 Jan 2009 22:02:28 -0000 Received: from 62-47-53-25.adsl.highway.telekom.at (EHLO [62.47.53.25]) [62.47.53.25] by mail.gmx.net (mp061) with SMTP; 14 Jan 2009 23:02:28 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19lcBtkY+Rl+HYaYPpYwIdOubnD3TCM9tJIrRNvlJ G9s2KxtLp8qUTs Message-ID: <496E60C0.7060801@gmx.at> Date: Wed, 14 Jan 2009 23:01:36 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <87sknl7e5d.fsf@jurta.org> In-Reply-To: <87sknl7e5d.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 > The list of files closer to the minibuffer is better than closer to the > dired buffer because the minibuffer is the place that the user looks at > while typing command's arguments for these files. Unless our user uses a separate minibuffer-only frame. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 22:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123197154915446 (code B ref 1806); Wed, 14 Jan 2009 22:25:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 22:19:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0EMJ6Ot015440 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 14:19:07 -0800 Received: from alfajor.home (vpn-132-204-232-55.acd.umontreal.ca [132.204.232.55]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n0EMJ4M7012212; Wed, 14 Jan 2009 17:19:05 -0500 Received: by alfajor.home (Postfix, from userid 20848) id D07591C15B; Wed, 14 Jan 2009 17:19:04 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> Date: Wed, 14 Jan 2009 17:19:04 -0500 In-Reply-To: <496E5F58.7030304@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 22:55:36 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3189=0 > What about putting this in `pop-up-windows'? Possible values are: > nil do not allow popping up windows > 'this selected window > 'below below selected window > 'below-split split selected window vertically > 'right right of selected window > 'right-split split selected window horizontally > 'bottom use window near bottom of frame > 'bottom-split split window near bottom of frame > t allow popping up windows > If an application (like dired) sees that this variable is t (the > default) it may ask to pop up the window wherever it's most suitable. > Otherwise, it has to respect the value chosen by the user. Like > (let ((pop-up-windows (if (eq pop-up-windows t) > 'bottom-split > pop-up-windows))) > (display-buffer ...)) But how would the user override this behavior in a way that can depend on the buffer being shown (i.e. via special-display-buffer-names)? Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 23:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123197499130758 (code B ref 1806); Wed, 14 Jan 2009 23:25:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 23:16:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0ENGNUf030750 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 15:16:24 -0800 Received: from alfajor.home (vpn-132-204-232-55.acd.umontreal.ca [132.204.232.55]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n0ENGLoM014769; Wed, 14 Jan 2009 18:16:22 -0500 Received: by alfajor.home (Postfix, from userid 20848) id DA63A1C15B; Wed, 14 Jan 2009 18:16:21 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <87sknl7e5d.fsf@jurta.org> <496E60C0.7060801@gmx.at> Date: Wed, 14 Jan 2009 18:16:21 -0500 In-Reply-To: <496E60C0.7060801@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 23:01:36 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3189=0 >> The list of files closer to the minibuffer is better than closer to the >> dired buffer because the minibuffer is the place that the user looks at >> while typing command's arguments for these files. > Unless our user uses a separate minibuffer-only frame. In that case the right behavior depends on many things (e.g. depends on where the minibuffer frame is located w.r.t to selected frame). To get this right most of time will require a lot of heuristic code, so we may as well punt on it and decide that any behavior that's OK for non-minibuffer-only situations is OK for minibuffer-only situations as well. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 14 Jan 2009 23:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12319763353234 (code B ref 1806); Wed, 14 Jan 2009 23:45:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Jan 2009 23:38:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0ENcqwf003228 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Jan 2009 15:38:53 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LNFJy-000N3E-N9; Thu, 15 Jan 2009 01:38:50 +0200 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> Date: Thu, 15 Jan 2009 01:37:07 +0200 In-Reply-To: <496E5F58.7030304@gmx.at> (martin rudalics's message of "Wed, 14 Jan 2009 22:55:36 +0100") Message-ID: <87k58x5ujg.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: ef6c50392af5ec65634338665e82f3c2 X-DrWeb-checked: yes >> And that's good: the list should be close to the question, not close to >> the dired buffer. > > If the dired buffer were not needed while asking the question, dired > could temporarily display that list in the dired window itself and > switch back to the dired buffer afterwards. But I never use dired. Actually Dired already displays that list in the Dired window itself when the list is too large and fills the whole window. But it would be bad to replace the Dired buffer with a small list with 2-3 filename lines and a lot of empty lines. So it is better to display a separate window near the minibuffer without empty lines using `fit-window-to-buffer'. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 15 Jan 2009 10:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12320158769737 (code B ref 1806); Thu, 15 Jan 2009 10:45:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Jan 2009 10:37:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0FAbl94009729 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 02:37:49 -0800 Received: (qmail invoked by alias); 15 Jan 2009 10:37:42 -0000 Received: from 62-47-53-123.adsl.highway.telekom.at (EHLO [62.47.53.123]) [62.47.53.123] by mail.gmx.net (mp036) with SMTP; 15 Jan 2009 11:37:42 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/akHNgzYLa6BZysdIvq2B92qCxtwcB40kwW84ec4 /MGwT6eG+Y3RcN Message-ID: <496F11C0.4080700@gmx.at> Date: Thu, 15 Jan 2009 11:36:48 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org, Juri Linkov 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 > But how would the user override this behavior in a way that can depend > on the buffer being shown (i.e. via special-display-buffer-names)? Customizing `pop-up-windows' would give (1) a general preference where and how `display-buffer' should pop up windows, and (2) a possibility to override decisions made by applications like dired on where and how to pop up windows. `special-display-buffer-names' and `special-display-regexps' would be handled as usually, before checking `pop-up-windows'. If we want, we can provide things like 'window-below or 'window-at-bottom as phony parameters as suggested earlier. All this is also a question of where and how to document behavior best. I tried to understand and document the special-display stuff but am pretty sure that I still haven't got it right yet. I strongly doubt that anyone but you really knows how this is supposed to work. OTOH `pop-up-windows' has a one line doc-string, so I thought we could try that first. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 15 Jan 2009 10:45:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12320158919747 (code B ref 1806); Thu, 15 Jan 2009 10:45:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Jan 2009 10:38:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0FAc3u7009739 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 02:38:04 -0800 Received: (qmail invoked by alias); 15 Jan 2009 10:37:56 -0000 Received: from 62-47-53-123.adsl.highway.telekom.at (EHLO [62.47.53.123]) [62.47.53.123] by mail.gmx.net (mp056) with SMTP; 15 Jan 2009 11:37:56 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+6Iwdus9S670j4QncLMgLB7nCJkp7lqXmU6RWryw jz1e9CZVZcmw07 Message-ID: <496F11CF.1080502@gmx.at> Date: Thu, 15 Jan 2009 11:37:03 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <87k58x5ujg.fsf@jurta.org> In-Reply-To: <87k58x5ujg.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 > Actually Dired already displays that list in the Dired window itself > when the list is too large and fills the whole window. But it would be > bad to replace the Dired buffer with a small list with 2-3 filename lines > and a lot of empty lines. So it is better to display a separate window > near the minibuffer without empty lines using `fit-window-to-buffer'. Reasonable. I suppose we should try to stay in the same "column" when frames are divided horizontally. Any fallback we should use when a bottom window can't be split? Split the selected one? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 15 Jan 2009 15:05:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123203156426739 (code B ref 1806); Thu, 15 Jan 2009 15:05:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Jan 2009 14:59:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0FExKb9026727 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 06:59:22 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgEAHvebklMCpxj/2dsb2JhbACBbM4VhW6BcQ X-IronPort-AV: E=Sophos;i="4.37,270,1231131600"; d="scan'208";a="32340220" Received: from 76-10-156-99.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 15 Jan 2009 09:59:14 -0500 Received: by pastel.home (Postfix, from userid 20848) id 6C4F07F41; Thu, 15 Jan 2009 09:59:14 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> Date: Thu, 15 Jan 2009 09:59:14 -0500 In-Reply-To: <496F11C0.4080700@gmx.at> (martin rudalics's message of "Thu, 15 Jan 2009 11:36:48 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> But how would the user override this behavior in a way that can depend >> on the buffer being shown (i.e. via special-display-buffer-names)? > Customizing `pop-up-windows' would give (1) a general preference where > and how `display-buffer' should pop up windows, and (2) a possibility to > override decisions made by applications like dired on where and how to > pop up windows. > `special-display-buffer-names' and `special-display-regexps' would be > handled as usually, before checking `pop-up-windows'. If we want, we > can provide things like 'window-below or 'window-at-bottom as phony > parameters as suggested earlier. Actually, those phony params aren't right. Now that you made me think some more about it, they're all mutually exclusive, so we really only want one such param whose value could be `same-frame', `same-window', or `near-minibuffer'. Those same values could be used for pop-up-windows. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 15 Jan 2009 23:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123206097122213 (code B ref 1806); Thu, 15 Jan 2009 23:15:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Jan 2009 23:09:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0FN9RBV022200 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 15:09:28 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LNbL3-000Lu1-S2; Fri, 16 Jan 2009 01:09:25 +0200 From: Juri Linkov To: Stefan Monnier Cc: martin rudalics , 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> Date: Fri, 16 Jan 2009 00:59:02 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 15 Jan 2009 09:59:14 -0500") Message-ID: <87ocy8fajt.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 233cb89e4cdd9c68f6fe52a505261b56 X-DrWeb-checked: yes >> `special-display-buffer-names' and `special-display-regexps' would be >> handled as usually, before checking `pop-up-windows'. If we want, we >> can provide things like 'window-below or 'window-at-bottom as phony >> parameters as suggested earlier. > > Actually, those phony params aren't right. Now that you made me think > some more about it, they're all mutually exclusive, so we really only > want one such param whose value could be `same-frame', `same-window', > or `near-minibuffer'. Those same values could be used for > pop-up-windows. While at this topic, could you also suggest a good parameter for the name of the current buffer to define where to display a new buffer. What I mean is that, for example, after clicking a link to the source file from the *Help* buffer, I want the source code (c. or .el) buffer to be displayed in the same window replacing the *Help* buffer. Since the name of the source code buffer can be anything, the only definite parameter is the name of the last buffer displayed in the current window ("*Help*"). -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 15 Jan 2009 23:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123206097322228 (code B ref 1806); Thu, 15 Jan 2009 23:15:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Jan 2009 23:09:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0FN9TbG022203 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 15:09:30 -0800 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LNbL5-000Hf1-Mh; Fri, 16 Jan 2009 01:09:27 +0200 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <87k58x5ujg.fsf@jurta.org> <496F11CF.1080502@gmx.at> Date: Fri, 16 Jan 2009 01:00:12 +0200 In-Reply-To: <496F11CF.1080502@gmx.at> (martin rudalics's message of "Thu, 15 Jan 2009 11:37:03 +0100") Message-ID: <87wscwdvk3.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 8d26fb09d298f8c1cb325fc86345eca8 X-DrWeb-checked: yes >> Actually Dired already displays that list in the Dired window itself >> when the list is too large and fills the whole window. But it would be >> bad to replace the Dired buffer with a small list with 2-3 filename lines >> and a lot of empty lines. So it is better to display a separate window >> near the minibuffer without empty lines using `fit-window-to-buffer'. > > Reasonable. I suppose we should try to stay in the same "column" when > frames are divided horizontally. Any fallback we should use when a > bottom window can't be split? Split the selected one? Creating a full-width window would fit more information, and the window width will be the same as the width of the minibuffer's window. This will more logically connect a new window to the minibuffer that is necessary for dired files and completions: +------------+------------+ | | | | | | | dired | other | | | | | | | +------------+ | | other | | | | | +------------+------------+ | file1.ext file2.ext | | file3.ext file4.ext | +-------------------------+ | Prompt: command | +-------------------------+ I think this would be the best layout, but not sure is it possible to create it using splitting from the initial configuration? +------------+------------+ | | | | | | | dired | other | | | | | | | +------------+ | | other | | | | | | | | | | | | | | +------------+------------+ | Prompt: command | +-------------------------+ -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 16 Jan 2009 02:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123207239613530 (code B ref 1806); Fri, 16 Jan 2009 02:25:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Jan 2009 02:19:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0G2Jrpc013524 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Jan 2009 18:19:54 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEANt9b0lMCpxj/2dsb2JhbACBbMwBhXGBdQ X-IronPort-AV: E=Sophos;i="4.37,274,1231131600"; d="scan'208";a="32383055" Received: from 76-10-156-99.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 15 Jan 2009 21:19:47 -0500 Received: by pastel.home (Postfix, from userid 20848) id 8187E7F41; Thu, 15 Jan 2009 21:19:47 -0500 (EST) From: Stefan Monnier To: Juri Linkov Cc: martin rudalics , 1806@debbugs.gnu.org Message-ID: 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> Date: Thu, 15 Jan 2009 21:19:47 -0500 In-Reply-To: <87ocy8fajt.fsf@jurta.org> (Juri Linkov's message of "Fri, 16 Jan 2009 00:59:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Juri" == Juri Linkov writes: >>> `special-display-buffer-names' and `special-display-regexps' would be >>> handled as usually, before checking `pop-up-windows'. If we want, we >>> can provide things like 'window-below or 'window-at-bottom as phony >>> parameters as suggested earlier. >> >> Actually, those phony params aren't right. Now that you made me think >> some more about it, they're all mutually exclusive, so we really only >> want one such param whose value could be `same-frame', `same-window', >> or `near-minibuffer'. Those same values could be used for >> pop-up-windows. > While at this topic, could you also suggest a good parameter for the > name of the current buffer to define where to display a new buffer. > What I mean is that, for example, after clicking a link to the source file > from the *Help* buffer, I want the source code (c. or .el) buffer to be > displayed in the same window replacing the *Help* buffer. Since the name > of the source code buffer can be anything, the only definite parameter is > the name of the last buffer displayed in the current window ("*Help*"). Not sure 'bout that. Probably special-display-buffer-names is not the bext place to use for that kind of information. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 16 Jan 2009 15:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12321176765384 (code B ref 1806); Fri, 16 Jan 2009 15:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Jan 2009 14:54:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0GEsSoN005378 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Jan 2009 06:54:30 -0800 Received: (qmail invoked by alias); 16 Jan 2009 14:54:21 -0000 Received: from 62-47-34-195.adsl.highway.telekom.at (EHLO [62.47.34.195]) [62.47.34.195] by mail.gmx.net (mp011) with SMTP; 16 Jan 2009 15:54:21 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+FrDlg4E2FuCDLVhu4znZzqWHI+YyPKibLLpf688 KzyyZnqRknhFA3 Message-ID: <49709F21.7010905@gmx.at> Date: Fri, 16 Jan 2009 15:52:17 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <87k58x5ujg.fsf@jurta.org> <496F11CF.1080502@gmx.at> <87wscwdvk3.fsf@jurta.org> In-Reply-To: <87wscwdvk3.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 > +------------+------------+ > | | | > | | | > | dired | other | > | | | > | | | > +------------+ | > | other | | > | | | > +------------+------------+ > | file1.ext file2.ext | > | file3.ext file4.ext | > +-------------------------+ > | Prompt: command | > +-------------------------+ > > I think this would be the best layout, but not sure is it possible > to create it using splitting from the initial configuration? Not really. Creating windows anew breaks the 'window property of overlays. ISTR that Lennart has some code to fix that, but the overhead may be considerable since you have to investigate all overlays and most of them usually don't have the 'window property. Here I simply split the root window to get the effect you mean. In any case, restoring the previous configuration when the window is no more needed is not entirely trivial either. I suppose, for the moment we have to split the "other" window below instead. That is, check if there is a window with the same left edge as the dired window and the maximum bottom edge of all windows on this frame. If that window cannot be split because it's too small or fixed height, try to split the selected window (the dired window) instead. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 20 Jan 2009 16:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123246735114016 (code B ref 1806); Tue, 20 Jan 2009 16:10:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 20 Jan 2009 16:02:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MDO_CABLE_TV3,MIXEDBDN,MURPHY_DRUGS_REL8,PHONENUMBER autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n0KG2Om7014010 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Jan 2009 08:02:26 -0800 Received: (qmail invoked by alias); 20 Jan 2009 16:02:18 -0000 Received: from 62-47-45-231.adsl.highway.telekom.at (EHLO [62.47.45.231]) [62.47.45.231] by mail.gmx.net (mp066) with SMTP; 20 Jan 2009 17:02:18 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18eGFEscRoeHGbaPFqscT8z9j2BM5himP5LKwT34n wUmYIu3FxHl6m4 Message-ID: <4975F4D5.5030000@gmx.at> Date: Tue, 20 Jan 2009 16:59:17 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070606070500000101000207" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68,0.53 This is a multi-part message in MIME format. --------------070606070500000101000207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please have a look at the attached (only lightly tested) patch. I didn't provide a similar service for `special-display-buffer-names' and `special-display-regexps' yet. `display-buffer' and `pop-to-buffer' behave "as usual" as long as the default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW are used. An application calling `display-buffer' or `pop-to-buffer' can specify the preferable window to split by setting NOT-THIS-WINDOW or OTHER-WINDOW appropriately. Users can specify their preferences (and override the application) by setting `pop-up-windows' appropriately. martin --------------070606070500000101000207 Content-Type: text/plain; name="window.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="window.el.diff" *** window.el.~1.179.~ 2009-01-16 17:41:41.046875000 +0100 --- window.el 2009-01-20 16:58:01.062500000 +0100 *************** *** 789,797 **** :version "21.1" :group 'windows) (defcustom pop-up-windows t ! "Non-nil means `display-buffer' should make a new window." ! :type 'boolean :group 'windows) (defcustom split-height-threshold 80 --- 789,843 ---- :version "21.1" :group 'windows) + ;; Make sure the following two variables always use the same values + ;; (sans `t'). + (defconst pop-up-windows-values + '(largest lru selected below right bottom-left top-left) + "List of preferences supported by `pop-up-windows'.") + (defcustom pop-up-windows t ! "Non-nil means `display-buffer' is allowed to make a new window. ! A non-empty list specifies the windows `display-buffer' will ! consider for splitting on the respective frame. The following ! entries are supported: ! ! largest ...... largest window ! lru .......... least recently used window ! selected ..... the frame's selected window ! below ........ window below frame's selected window ! right ........ window right of frame's selected window ! bottom-left .. window in lower left corner of frame ! top-left ..... window in upper left corner of frame ! t ............ window specified by application ! ! Note that when `display-buffer' finds the value t, it will use ! the value specified by the function that called `display-buffer' ! provided there is one, and ignore this entry otherwise. If the ! entire list equals `(t)', `display-buffer' will pop up a new ! window if and only if the application specified value produces ! one. If this list does not contain the value t, `display-buffer' ! will ignore any value specified by an application. ! ! The default value t stands for the list `(t largest lru)'. This ! means that Emacs will first try a value specified by the ! application that called `display-buffer'. If there's no such ! value, or the window specified by that value doesn't exist, or ! that window can't be split, `display-buffer' will try to split ! the largest window and, if that fails too, the least recently ! used window." ! :type '(choice ! (const :tag "Disallow" nil) ! (const :tag "Allow" t) ! (repeat :tag "Preferences" ! (choice ! (const :tag "Largest" largest) ! (const :tag "Least Recently Used" lru) ! (const :tag "Selected" selected) ! (const :tag "Below Selected" below) ! (const :tag "Right of Selected" right) ! (const :tag "Bottom Left" bottom-left) ! (const :tag "Top Left" top-left) ! (const :tag "Application Specified" t)))) :group 'windows) (defcustom split-height-threshold 80 *************** *** 957,962 **** --- 1003,1099 ---- (enlarge-window (/ (- (window-height window) (window-height)) 2)) (error nil))))) + (defun window--probe-windows (frame windows probe) + "Find window in WINDOWS satisfying PROBE on FRAME. + To be called by `window--pop-up-window' exclusively." + (cond + ((eq probe 'selected) + (let ((window (frame-selected-window frame))) + (car (member window windows)))) + ((eq probe 'largest) + (get-largest-window frame t)) + ((eq probe 'lru) + (get-lru-window frame t)) + ((memq probe '(below right bottom-left top-left)) + (let ((this-edges + (window-edges + (cond + ((memq probe '(below right)) + (frame-selected-window frame)) + ((memq probe '(top-left bottom-left)) + (frame-root-window frame))))) + edges) + (catch 'found + (dolist (window windows) + (setq edges (window-edges window)) + (when (or (and (eq probe 'below) + (= (nth 1 edges) (nth 3 this-edges)) + (= (nth 2 edges) (nth 2 this-edges))) + (and (eq probe 'right) + (= (nth 0 edges) (nth 2 this-edges)) + (= (nth 1 edges) (nth 1 this-edges))) + (and (eq probe 'top-left) + (= (nth 0 edges) (nth 0 this-edges)) + (= (nth 1 edges) (nth 1 this-edges))) + (and (eq probe 'bottom-left) + (= (nth 0 edges) (nth 0 this-edges)) + (= (nth 3 edges) (nth 3 this-edges)))) + (throw 'found window)))))))) + + (defun window--pop-up-window (buffer frame user system) + "Pop up a new window for BUFFER on FRAME. + FRAME nil means the selected frame. If FRAME cannot be split, + try to split a window on the last nonminibuffer frame instead. + + USER, if not nil and not t, is a list specifying the user's + preferences for finding the window to split. For a list of + supported values see the variable `pop-up-windows-values'. The + special value t means to use SYSTEM, if applicable, instead. For + the meaning of all values, consult the documentation of the + variable `pop-up-windows'. If USER equals t, this means to use + the list `(t largest lru)' instead. + + SYSTEM, provided it is any of `pop-up-windows-values', + substitutes an occurence of t within USER." + ;; FRAME nil means use the selected frame. + (setq frame (or frame (selected-frame))) + ;; But make sure our frame is not a minibuffer frame. + (when (window-minibuffer-p (frame-selected-window frame)) + (setq frame (last-nonminibuffer-frame))) + (unless (and (frame-parameter frame 'unsplittable) + ;; If the frame cannot be split have a look at + ;; `last-nonminibuffer-frame'. + (or (not (eq frame (selected-frame))) + (not (setq frame (last-nonminibuffer-frame))) + (not (window--frame-usable-p frame)) + (frame-parameter frame 'unsplittable))) + (when (eq user t) + ;; USER t means use '(t largest lru) instead. + (setq user '(t largest lru))) + (let* ((this-window (frame-selected-window frame)) + (windows (window-list frame 'nomini this-window)) + (probe (car user)) + window window-to-use) + ;; While we have not yet found a usable window, scan `windows' for + ;; a windows satisfying `probe'. + (while (and (not window-to-use) windows probe) + (setq window + (if (eq probe t) + ;; SYSTEM overrides t in USER. + (when (memq system pop-up-windows-values) + ;; SYSTEM is a valid value, so use it. + (window--probe-windows frame windows system)) + (window--probe-windows frame windows probe))) + (when window + (setq window-to-use (window--try-to-split-window window))) + (unless window-to-use + ;; Don't consider `window' again. + (setq windows (remove window windows)) + (setq user (cdr user)) + (setq probe (car user)))) + (when window-to-use + (window--display-buffer-2 buffer window-to-use))))) + (defun window--display-buffer-1 (window) "Raise the frame containing WINDOW. Do not raise the selected frame. Return WINDOW." *************** *** 987,993 **** Optional argument NOT-THIS-WINDOW non-nil means display the buffer in a window other than the selected one, even if it is ! already displayed in the selected window. Optional argument FRAME specifies which frames to investigate when the specified buffer is already displayed. If the buffer is --- 1124,1135 ---- Optional argument NOT-THIS-WINDOW non-nil means display the buffer in a window other than the selected one, even if it is ! already displayed in the selected window. As a special case, if ! NOT-THIS-WINDOW is any of the values in `pop-up-windows-values', ! this means to use that for finding a window to split. The ! documentation of the variable `pop-up-windows' contains an ! explanation of what these values mean as well as when such a ! value is applied. Optional argument FRAME specifies which frames to investigate when the specified buffer is already displayed. If the buffer is *************** *** 1009,1017 **** consider all visible or iconified frames." (interactive "BDisplay buffer:\nP") (let* ((can-use-selected-window ! ;; The selected window is usable unless either NOT-THIS-WINDOW ! ;; is non-nil, it is dedicated to its buffer, or it is the ! ;; `minibuffer-window'. (not (or not-this-window (window-dedicated-p (selected-window)) (window-minibuffer-p)))) --- 1151,1159 ---- consider all visible or iconified frames." (interactive "BDisplay buffer:\nP") (let* ((can-use-selected-window ! ;; The selected window is usable unless either ! ;; NOT-THIS-WINDOW is non-nil, it is dedicated to its ! ;; buffer, or it is the `minibuffer-window'. (not (or not-this-window (window-dedicated-p (selected-window)) (window-minibuffer-p)))) *************** *** 1039,1046 **** (funcall display-buffer-function buffer not-this-window)) ((and (not not-this-window) (eq (window-buffer (selected-window)) buffer)) ! ;; The selected window already displays BUFFER and ! ;; `not-this-window' is nil, so use it. (window--display-buffer-1 (selected-window))) ((and can-use-selected-window (same-window-p name-of-buffer)) ;; If the buffer's name tells us to use the selected window do so. --- 1181,1188 ---- (funcall display-buffer-function buffer not-this-window)) ((and (not not-this-window) (eq (window-buffer (selected-window)) buffer)) ! ;; The selected window already displays BUFFER and NOT-THIS-WINDOW ! ;; is nil, so use it. (window--display-buffer-1 (selected-window))) ((and can-use-selected-window (same-window-p name-of-buffer)) ;; If the buffer's name tells us to use the selected window do so. *************** *** 1073,1093 **** (window--display-buffer-2 buffer (frame-selected-window (funcall pop-up-frame-function)))) ((and pop-up-windows ! ;; Make a new window. ! (or (not (frame-parameter frame-to-use 'unsplittable)) ! ;; If the selected frame cannot be split look at ! ;; `last-nonminibuffer-frame'. ! (and (eq frame-to-use (selected-frame)) ! (setq frame-to-use (last-nonminibuffer-frame)) ! (window--frame-usable-p frame-to-use) ! (not (frame-parameter frame-to-use 'unsplittable)))) ! ;; Attempt to split largest or least recently used window. ! (setq window-to-use ! (or (window--try-to-split-window ! (get-largest-window frame-to-use t)) ! (window--try-to-split-window ! (get-lru-window frame-to-use t)))) ! (window--display-buffer-2 buffer window-to-use))) ((let ((window-to-undedicate ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate ;; the selected window to its buffer, to avoid that some of --- 1215,1222 ---- (window--display-buffer-2 buffer (frame-selected-window (funcall pop-up-frame-function)))) ((and pop-up-windows ! (window--pop-up-window ! buffer frame-to-use pop-up-windows not-this-window))) ((let ((window-to-undedicate ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate ;; the selected window to its buffer, to avoid that some of *************** *** 1129,1134 **** --- 1258,1269 ---- already visible in the selected window, and ignore `same-window-regexps' and `same-window-buffer-names'. + As a special case, if OTHER-WINDOW is any of the values in + `pop-up-windows-values', this means to use that value for finding + a suitable window to split. The documentation of the variable + `pop-up-windows' contains an explanation of what these values + mean as well as when such a value is applied. + If the window to show BUFFER-OR-NAME is not on the selected frame, raise that window's frame and give it input focus. --------------070606070500000101000207-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: "Stefan Monnier" , 1806@debbugs.gnu.org Resent-From: "Stefan Monnier" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 21 Jan 2009 03:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.123250631216609 (code B ref 1806); Wed, 21 Jan 2009 03:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 21 Jan 2009 02:51:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.g-wis.com (mail.g-wis.com [204.250.154.18]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0L2pm8v016603 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Jan 2009 18:51:50 -0800 thread-index: Acl7cy7xF3vYD+ubT6qMywV28zL3GQ== X-Received-From-Address: 69.38.23.210 X-Envelope-From: monnier@iro.umontreal.ca X-Envelope-To: juri@jurta.org, monnier@iro.umontreal.ca, 1806@debbugs.gnu.org, rudalics@gmx.at Received: from ceviche.home ([69.38.23.210]) by mail.g-wis.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 18:51:38 -0800 Received: by ceviche.home (Postfix, from userid 20848) id EEE88B400C; Tue, 20 Jan 2009 21:51:37 -0500 (EST) From: "Stefan Monnier" To: "martin rudalics" Content-Transfer-Encoding: 7bit Cc: "Juri Linkov" , <1806@debbugs.gnu.org> Message-ID: Content-Class: urn:content-classes:message Importance: normal Priority: normal References: <87r63gzcap.fsf@jurta.org> <87prj0uxq8.fsf@jurta.org><4963A229.1030609@gmx.at> <87aba4qh1b.fsf@jurta.org><496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org><4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org><4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org><49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org><496DF4B9.3080805@gmx.at><496E5F58.7030304@gmx.at><496F11C0.4080700@gmx.at><87ocy8fajt.fsf@jurta.org><4975F4D5.5030000@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Date: Tue, 20 Jan 2009 21:51:37 -0500 In-Reply-To: <4975F4D5.5030000@gmx.at> (martin rudalics's message of "Tue, 20Jan 2009 16:59:17 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Jan 2009 02:51:38.0876 (UTC) FILETIME=[2E8603C0:01C97B73] > Please have a look at the attached (only lightly tested) patch. I > didn't provide a similar service for `special-display-buffer-names' and > `special-display-regexps' yet. > `display-buffer' and `pop-to-buffer' behave "as usual" as long as the > default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW > are used. An application calling `display-buffer' or `pop-to-buffer' > can specify the preferable window to split by setting NOT-THIS-WINDOW or > OTHER-WINDOW appropriately. Users can specify their preferences (and > override the application) by setting `pop-up-windows' appropriately. I think this is post-23.1. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 28 Apr 2009 23:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124095988414574 (code B ref 1806); Tue, 28 Apr 2009 23:10:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 28 Apr 2009 23:04:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n3SN4ZYB014562 for <1806@emacsbugs.donarmstrong.com>; Tue, 28 Apr 2009 16:04:37 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LywLm-000KE1-Ui; Wed, 29 Apr 2009 02:04:31 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87prj0uxq8.fsf@jurta.org> <4963A229.1030609@gmx.at> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> Date: Wed, 29 Apr 2009 01:58:00 +0300 In-Reply-To: <4975F4D5.5030000@gmx.at> (martin rudalics's message of "Tue, 20 Jan 2009 16:59:17 +0100") Message-ID: <87y6tk1j47.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 068dd79c68aafbc760c35e97c5d420ed X-DrWeb-checked: yes > Please have a look at the attached (only lightly tested) patch. > I didn't provide a similar service for `special-display-buffer-names' > and `special-display-regexps' yet. > > `display-buffer' and `pop-to-buffer' behave "as usual" as long as the > default values for `pop-up-windows', NOT-THIS-WINDOW, and OTHER-WINDOW > are used. An application calling `display-buffer' or `pop-to-buffer' > can specify the preferable window to split by setting NOT-THIS-WINDOW or > OTHER-WINDOW appropriately. Users can specify their preferences (and > override the application) by setting `pop-up-windows' appropriately. This might be good for post-23.1, but the reported annoyance is still here, so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'. Martin, do you think this is possible without reverting `dired-pop-to-buffer' to pre-December 2008 state, and making necessary changes in window.el thus providing the same behavior that was in `dired-pop-to-buffer'? -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 29 Apr 2009 07:25:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124098945311823 (code B ref 1806); Wed, 29 Apr 2009 07:25:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 29 Apr 2009 07:17:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n3T7HTjU011802 for <1806@emacsbugs.donarmstrong.com>; Wed, 29 Apr 2009 00:17:30 -0700 Received: (qmail invoked by alias); 29 Apr 2009 07:17:23 -0000 Received: from 62-47-45-129.adsl.highway.telekom.at (EHLO [62.47.45.129]) [62.47.45.129] by mail.gmx.net (mp056) with SMTP; 29 Apr 2009 09:17:23 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18Yh89Z/qgYF0pMEJrHq4d44qwgbwjSLy+Km/nww3 vu4F0Q09bC2ZZh Message-ID: <49F7FE14.8010107@gmx.at> Date: Wed, 29 Apr 2009 09:13:24 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87prj0uxq8.fsf@jurta.org> <4963A229.1030609@gmx.at> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> In-Reply-To: <87y6tk1j47.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 > This might be good for post-23.1, but the reported annoyance is still here, > so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'. > > Martin, do you think this is possible without reverting `dired-pop-to-buffer' > to pre-December 2008 state, and making necessary changes in window.el > thus providing the same behavior that was in `dired-pop-to-buffer'? `dired-pop-to-buffer' could bind `split-window-preferred-function' to a function that tries to always split the selected window instead of whatever window was chosen by `display-buffer' but that would override any user customizations of `split-window-preferred-function'. We could also provide a variable `split-window-preferred-window', nil by default, which the window choosing mechanism of `display-buffer' would respect if bound to some live window. And we could turn this variable into an option (now or later). martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 29 Apr 2009 11:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12410036829732 (code B ref 1806); Wed, 29 Apr 2009 11:20:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 29 Apr 2009 11:14:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3TBEbQC009724 for <1806@emacsbugs.donarmstrong.com>; Wed, 29 Apr 2009 04:14:40 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1Lz7kJ-0000b0-Cr; Wed, 29 Apr 2009 14:14:35 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> Date: Wed, 29 Apr 2009 12:54:08 +0300 In-Reply-To: <49F7FE14.8010107@gmx.at> (martin rudalics's message of "Wed, 29 Apr 2009 09:13:24 +0200") Message-ID: <878wljd8nn.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: d0b3bc0b24c4067239780ad28ae5b444 X-DrWeb-checked: yes >> This might be good for post-23.1, but the reported annoyance is still here, >> so we need just to restore the old 22.1 behavior of `dired-pop-to-buffer'. >> >> Martin, do you think this is possible without reverting `dired-pop-to-buffer' >> to pre-December 2008 state, and making necessary changes in window.el >> thus providing the same behavior that was in `dired-pop-to-buffer'? > > `dired-pop-to-buffer' could bind `split-window-preferred-function' to a > function that tries to always split the selected window instead of > whatever window was chosen by `display-buffer' but that would override > any user customizations of `split-window-preferred-function'. We could compare `split-window-preferred-function' with its default value and override it in dired only when it has the default value. Otherwise we could define a new option `dired-split-window-preferred-function'. > We could also provide a variable `split-window-preferred-window', nil by > default, which the window choosing mechanism of `display-buffer' would > respect if bound to some live window. And we could turn this variable > into an option (now or later). Do you mean `split-window-preferred-window' as a user-defined value that replaces the `window' argument of `split-window-preferred-function'? -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 29 Apr 2009 12:50:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124100889332136 (code B ref 1806); Wed, 29 Apr 2009 12:50:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 29 Apr 2009 12:41:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n3TCfSRl032130 for <1806@emacsbugs.donarmstrong.com>; Wed, 29 Apr 2009 05:41:29 -0700 Received: (qmail invoked by alias); 29 Apr 2009 12:41:22 -0000 Received: from 62-47-59-107.adsl.highway.telekom.at (EHLO [62.47.59.107]) [62.47.59.107] by mail.gmx.net (mp007) with SMTP; 29 Apr 2009 14:41:22 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/EspNr+dzE4hkK9J2HC9i3StTuaeOlGiqXCN75cR atTgeGlue6tZkc Message-ID: <49F84A9D.8040901@gmx.at> Date: Wed, 29 Apr 2009 14:39:57 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <878wljd8nn.fsf@mail.jurta.org> In-Reply-To: <878wljd8nn.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 > We could compare `split-window-preferred-function' with its default value > and override it in dired only when it has the default value. It would be more difficult to document such behavior than to implement it. > Otherwise we could define a new option `dired-split-window-preferred-function'. Didn't you cite some other package that wanted such a thing? >> We could also provide a variable `split-window-preferred-window', nil by >> default, which the window choosing mechanism of `display-buffer' would >> respect if bound to some live window. And we could turn this variable >> into an option (now or later). > > Do you mean `split-window-preferred-window' as a user-defined value > that replaces the `window' argument of `split-window-preferred-function'? Yes, provided `split-window-preferred-function' then still wants such an argument. I'd simply check whether `split-window-preferred-window' is a live window that can be split by `split-window-preferred-function'. If not, I'd proceed in the usual way. Later on, we could allow as value of `split-window-preferred-window' also a function that computes such a window on-the-fly. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 29 Apr 2009 15:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12410189189679 (code B ref 1806); Wed, 29 Apr 2009 15:35:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 29 Apr 2009 15:28:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3TFSYcu009673 for <1806@emacsbugs.donarmstrong.com>; Wed, 29 Apr 2009 08:28:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFABsP+ElMCpT6/2dsb2JhbACBUM5Hg3UFhTo X-IronPort-AV: E=Sophos;i="4.40,266,1238990400"; d="scan'208";a="37764294" Received: from 76-10-148-250.dsl.teksavvy.com (HELO ceviche.home) ([76.10.148.250]) by ironport2-out.teksavvy.com with ESMTP; 29 Apr 2009 11:28:29 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 4CFA7B5227; Wed, 29 Apr 2009 11:28:29 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> Date: Wed, 29 Apr 2009 11:28:29 -0400 In-Reply-To: <49F7FE14.8010107@gmx.at> (martin rudalics's message of "Wed, 29 Apr 2009 09:13:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > `dired-pop-to-buffer' could bind `split-window-preferred-function' to a > function that tries to always split the selected window instead of > whatever window was chosen by `display-buffer' but that would override > any user customizations of `split-window-preferred-function'. Why would it override it? It would of course bind split-window-preferred-function to a function that selects the right window and then calls the previous value. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 30 Apr 2009 09:15:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124108250922591 (code B ref 1806); Thu, 30 Apr 2009 09:15:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 30 Apr 2009 09:08:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n3U98P6C022567 for <1806@emacsbugs.donarmstrong.com>; Thu, 30 Apr 2009 02:08:26 -0700 Received: (qmail invoked by alias); 30 Apr 2009 09:08:19 -0000 Received: from 62-47-58-178.adsl.highway.telekom.at (EHLO [62.47.58.178]) [62.47.58.178] by mail.gmx.net (mp006) with SMTP; 30 Apr 2009 11:08:19 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+LhIgffqqLoEw67Z8CtutdiCGNSzp7Xs+eaMiA10 tz7wtGVKQC6MBI Message-ID: <49F969F9.5010603@gmx.at> Date: Thu, 30 Apr 2009 11:06:01 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 > Why would it override it? It would of course bind > split-window-preferred-function to a function that selects the right > window and then calls the previous value. Maybe you can come up with some advanced technique to do that but here I would have to define a variable to save the current (user provided) `split-window-preferred-function' and call the function I save there within the body of the function provided by dired. Hence an extra variable would be needed anyway and I suppose it's easier to define that in window.el rather than in all packages that want to change the window to split (IIRC Calendar was one of these). martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 30 Apr 2009 13:40:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12410983333763 (code B ref 1806); Thu, 30 Apr 2009 13:40:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 30 Apr 2009 13:32:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3UDW938003752 for <1806@emacsbugs.donarmstrong.com>; Thu, 30 Apr 2009 06:32:10 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1LzVdS-0009hZ-SU; Thu, 30 Apr 2009 15:45:06 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <878wljd8nn.fsf@mail.jurta.org> <49F84A9D.8040901@gmx.at> Date: Thu, 30 Apr 2009 14:47:33 +0300 In-Reply-To: <49F84A9D.8040901@gmx.at> (martin rudalics's message of "Wed, 29 Apr 2009 14:39:57 +0200") Message-ID: <87tz46tjgq.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 04c94f097e8f9f394bef3a87cbd9ccf9 X-DrWeb-checked: yes > Didn't you cite some other package that wanted such a thing? Yes, Proced, Calendar, etc. I believe it is possible to define one common splitting function (that finds the right window to split and splits it vertically) for all these packages in window.el, but I still think even this common function should be customizable. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 30 Apr 2009 18:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124111615624091 (code B ref 1806); Thu, 30 Apr 2009 18:35:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 30 Apr 2009 18:29:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER,XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n3UITC52024077 for <1806@emacsbugs.donarmstrong.com>; Thu, 30 Apr 2009 11:29:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAMuK+UnO+ITX/2dsb2JhbACBUM9BgkCBPwWFOg X-IronPort-AV: E=Sophos;i="4.40,274,1238990400"; d="scan'208";a="37829352" Received: from 206-248-132-215.dsl.teksavvy.com (HELO pastel.home) ([206.248.132.215]) by ironport2-out.teksavvy.com with ESMTP; 30 Apr 2009 14:29:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id 055347F64; Thu, 30 Apr 2009 14:29:07 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> Date: Thu, 30 Apr 2009 14:29:06 -0400 In-Reply-To: <49F969F9.5010603@gmx.at> (martin rudalics's message of "Thu, 30 Apr 2009 11:06:01 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Why would it override it? It would of course bind >> split-window-preferred-function to a function that selects the right >> window and then calls the previous value. > Maybe you can come up with some advanced technique to do that but here I > would have to define a variable to save the current (user provided) > `split-window-preferred-function' and call the function I save there > within the body of the function provided by dired. I'd use something like (lexical-let ((oldfun split-window-preferred-function)) (let ((split-window-preferred-function (lambda () (with-selected-window TOTO (funcall oldfun))))) BLABLA)) > Hence an extra variable would be needed anyway and I suppose it's > easier to define that in window.el rather than in all packages that > want to change the window to split (IIRC Calendar was one of these). The above coding should be close to "standard practice" for locally rebinding a *-function variable. The "extra variable" doesn't matter, it's not like we count variables. Maybe what you're getting at is that we should make a hook to influence the window-choice. Maybe so. But it doesn't seem urgent. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 01 May 2009 10:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124117242820243 (code B ref 1806); Fri, 01 May 2009 10:15:02 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 1 May 2009 10:07:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MIXEDBDN,MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n41A73Mh020233 for <1806@emacsbugs.donarmstrong.com>; Fri, 1 May 2009 03:07:05 -0700 Received: (qmail invoked by alias); 01 May 2009 10:06:58 -0000 Received: from 62-47-59-240.adsl.highway.telekom.at (EHLO [62.47.59.240]) [62.47.59.240] by mail.gmx.net (mp026) with SMTP; 01 May 2009 12:06:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX185bdd0CUY5pdXcrOKEh4NEhIqAryP5hLcEsjNw6s 8IUy+D3iPglb7M Message-ID: <49FAC921.5010201@gmx.at> Date: Fri, 01 May 2009 12:04:17 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030805010707070202040401" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71,0.64 This is a multi-part message in MIME format. --------------030805010707070202040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Maybe you can come up with some advanced technique to do that but here I >> would have to define a variable to save the current (user provided) >> `split-window-preferred-function' and call the function I save there >> within the body of the function provided by dired. > > I'd use something like > > (lexical-let ((oldfun split-window-preferred-function)) > (let ((split-window-preferred-function > (lambda () (with-selected-window TOTO (funcall oldfun))))) > BLABLA)) We probably need something like in the attached patch but my knowledge of closures within Elisp is very limited. > The above coding should be close to "standard practice" for locally > rebinding a *-function variable. The "extra variable" doesn't matter, > it's not like we count variables. > > Maybe what you're getting at is that we should make a hook to influence > the window-choice. Maybe so. But it doesn't seem urgent. I was aiming at an extra variable to work around "advanced techniques" like closures. `lexical-let' doesn't even indent reasonably :-( martin --------------030805010707070202040401 Content-Type: text/plain; name="dired.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dired.el.diff" *** dired.el.~1.422.~ 2009-04-18 08:32:56.546875000 +0200 --- dired.el 2009-05-01 11:47:49.109375000 +0200 *************** *** 2686,2694 **** (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! ;; Don't split window horizontally. (Bug#1806) ! (let (split-width-threshold) ! (pop-to-buffer (get-buffer-create buf))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit ;; Try to not delete window when we want to display less than --- 2686,2696 ---- (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! (lexical-let ((old-fun split-window-preferred-function) ! (old-window (selected-window))) ! (let ((split-window-preferred-function ! (lambda () (with-selected-window old-window (funcall old-fun))))) ! (pop-to-buffer (get-buffer-create buf)))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit ;; Try to not delete window when we want to display less than --------------030805010707070202040401-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Fri, 01 May 2009 17:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124119868212489 (code B ref 1806); Fri, 01 May 2009 17:30:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 1 May 2009 17:24:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n41HObkL012482 for <1806@emacsbugs.donarmstrong.com>; Fri, 1 May 2009 10:24:39 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n41HOcL8006800; Fri, 1 May 2009 13:24:38 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 91C903A2EA; Fri, 1 May 2009 13:24:36 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> Date: Fri, 01 May 2009 13:24:36 -0400 In-Reply-To: <49FAC921.5010201@gmx.at> (martin rudalics's message of "Fri, 01 May 2009 12:04:17 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3266=0 > We probably need something like in the attached patch but my knowledge > of closures within Elisp is very limited. That looks fine. > I was aiming at an extra variable to work around "advanced techniques" > like closures. Closures are (should be) bread&butter; not "advanced". > `lexical-let' doesn't even indent reasonably :-( I don't know of any such bug, so please give details. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 07:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124124848517918 (code B ref 1806); Sat, 02 May 2009 07:20:02 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 07:14:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n427EeIJ017907 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 00:14:42 -0700 Received: (qmail invoked by alias); 02 May 2009 07:14:34 -0000 Received: from 62-47-36-172.adsl.highway.telekom.at (EHLO [62.47.36.172]) [62.47.36.172] by mail.gmx.net (mp044) with SMTP; 02 May 2009 09:14:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/w9BguAfTwkG6TIJPV43eT0Dzh39B/K3GQqdydDP /tbUXEzaFZlSr8 Message-ID: <49FBEF5A.7080607@gmx.at> Date: Sat, 02 May 2009 08:59:38 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 > Closures are (should be) bread&butter; not "advanced". > >> `lexical-let' doesn't even indent reasonably :-( > > I don't know of any such bug, so please give details. It won't indent correctly from scratch. I do have to load the CL library first which hardly qualifies as bread&butter ;-) martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 12:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12412653283601 (code B ref 1806); Sat, 02 May 2009 12:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 11:55:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n42BtO3j003499 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 04:55:25 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M0DoQ-00014t-KG; Sat, 02 May 2009 14:55:22 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> Date: Sat, 02 May 2009 14:48:57 +0300 In-Reply-To: <49FAC921.5010201@gmx.at> (martin rudalics's message of "Fri, 01 May 2009 12:04:17 +0200") Message-ID: <878wlfk9lm.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 4204c266f86c3e9b1e0231505dd73b85 X-DrWeb-checked: yes > (defun dired-pop-to-buffer (buf) > "Pop up buffer BUF in a way suitable for Dired." > ! ;; Don't split window horizontally. (Bug#1806) > ! (let (split-width-threshold) > ! (pop-to-buffer (get-buffer-create buf))) > ;; If dired-shrink-to-fit is t, make its window fit its contents. > (when dired-shrink-to-fit > ;; Try to not delete window when we want to display less than > --- 2686,2696 ---- > > (defun dired-pop-to-buffer (buf) > "Pop up buffer BUF in a way suitable for Dired." > ! (lexical-let ((old-fun split-window-preferred-function) > ! (old-window (selected-window))) > ! (let ((split-window-preferred-function > ! (lambda () (with-selected-window old-window (funcall old-fun))))) > ! (pop-to-buffer (get-buffer-create buf)))) > ;; If dired-shrink-to-fit is t, make its window fit its contents. > (when dired-shrink-to-fit > ;; Try to not delete window when we want to display less than Is your patch intended to fix a problem I reported? I tried it and it makes the current state worse. It works incorrectly even in the one-window configuration - it splits it horizontally and displays a list of files in a side window. However, when I replaced (funcall old-fun) with (funcall 'split-window-vertically) in your patch, it works perfectly in all configurations I tried. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 13:11:12 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124126985927052 (code B ref 1806); Sat, 02 May 2009 13:11:12 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 13:10:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n42DAsq4027036 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 06:10:55 -0700 Received: (qmail invoked by alias); 02 May 2009 13:10:48 -0000 Received: from 62-47-62-131.adsl.highway.telekom.at (EHLO [62.47.62.131]) [62.47.62.131] by mail.gmx.net (mp070) with SMTP; 02 May 2009 15:10:48 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18CV4leF4QCk//tyilpOJOLM6d+fEu/JshAMHNWhX Of0mRL8YygR2LL Message-ID: <49FC4600.8010902@gmx.at> Date: Sat, 02 May 2009 15:09:20 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> In-Reply-To: <878wlfk9lm.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 > Is your patch intended to fix a problem I reported? Hopefully. > I tried it and > it makes the current state worse. It works incorrectly even in the > one-window configuration - it splits it horizontally and displays > a list of files in a side window. Did you try it after applying my patch for window.el? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 14:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12412724726936 (code B ref 1806); Sat, 02 May 2009 14:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 13:54:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n42DsSFf006930 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 06:54:29 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M0Ffd-000GKp-VQ; Sat, 02 May 2009 16:54:26 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <49FC4600.8010902@gmx.at> Date: Sat, 02 May 2009 16:54:02 +0300 In-Reply-To: <49FC4600.8010902@gmx.at> (martin rudalics's message of "Sat, 02 May 2009 15:09:20 +0200") Message-ID: <877i0zipad.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: ef6c50392af5ec65634338665e82f3c2 X-DrWeb-checked: yes >> Is your patch intended to fix a problem I reported? > > Hopefully. > >> I tried it and >> it makes the current state worse. It works incorrectly even in the >> one-window configuration - it splits it horizontally and displays >> a list of files in a side window. > > Did you try it after applying my patch for window.el? Yes, with your patch for window.el and in a frame wider than 160 columns. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 19:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12412910532861 (code B ref 1806); Sat, 02 May 2009 19:10:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 19:04:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,MIXEDBDN, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n42J48gH002849 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 12:04:09 -0700 Received: (qmail invoked by alias); 02 May 2009 19:04:02 -0000 Received: from 88-117-36-121.adsl.highway.telekom.at (EHLO [88.117.36.121]) [88.117.36.121] by mail.gmx.net (mp048) with SMTP; 02 May 2009 21:04:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+rZBAY6WSrPFry/Mroa3pn9rZHJ28trefUB+uTYQ k/CA23YhBox4e5 Message-ID: <49FC9694.5050008@gmx.at> Date: Sat, 02 May 2009 20:53:08 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: Stefan Monnier , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <49FC4600.8010902@gmx.at> <877i0zipad.fsf@mail.jurta.org> In-Reply-To: <877i0zipad.fsf@mail.jurta.org> Content-Type: multipart/mixed; boundary="------------060008010802030009080507" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78,0.65 This is a multi-part message in MIME format. --------------060008010802030009080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Did you try it after applying my patch for window.el? > > Yes, with your patch for window.el and in a frame wider than 160 columns. My bad. Does the attached patch give better results? martin --------------060008010802030009080507 Content-Type: text/plain; name="dired.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dired.el.diff" *** dired.el.~1.422.~ 2009-04-18 08:32:56.546875000 +0200 --- dired.el 2009-05-02 20:49:03.656250000 +0200 *************** *** 2686,2694 **** (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! ;; Don't split window horizontally. (Bug#1806) ! (let (split-width-threshold) ! (pop-to-buffer (get-buffer-create buf))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit ;; Try to not delete window when we want to display less than --- 2686,2698 ---- (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! (lexical-let ((old-fun split-window-preferred-function) ! (old-window (selected-window))) ! (let ((split-window-preferred-function ! (lambda () ! (let (split-width-threshold) ! (with-selected-window old-window (funcall old-fun)))))) ! (pop-to-buffer (get-buffer-create buf)))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit ;; Try to not delete window when we want to display less than --------------060008010802030009080507-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 21:05:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12412979473934 (code B ref 1806); Sat, 02 May 2009 21:05:11 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 20:59:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n42Kx0ar003924 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 13:59:03 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M0MIV-000EEG-Ez; Sat, 02 May 2009 23:58:59 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <49FC4600.8010902@gmx.at> <877i0zipad.fsf@mail.jurta.org> <49FC9694.5050008@gmx.at> Date: Sat, 02 May 2009 23:57:11 +0300 In-Reply-To: <49FC9694.5050008@gmx.at> (martin rudalics's message of "Sat, 02 May 2009 20:53:08 +0200") Message-ID: <87ws8zgr4m.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: ba97961d419726f65b83e74233c16638 X-DrWeb-checked: yes >>> Did you try it after applying my patch for window.el? >> >> Yes, with your patch for window.el and in a frame wider than 160 columns. > > My bad. Does the attached patch give better results? It is no much better than your previous patch - when windows are already split horizontally, it displays a list of files in the side window instead of vertically splitting the dired buffer's window and creating a new window below it. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 02 May 2009 22:50:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12413043332688 (code B ref 1806); Sat, 02 May 2009 22:50:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 2 May 2009 22:45:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n42MjTpq002543 for <1806@emacsbugs.donarmstrong.com>; Sat, 2 May 2009 15:45:30 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M0NxX-000862-RL; Sun, 03 May 2009 01:45:28 +0300 From: Juri Linkov To: 1806@debbugs.gnu.org Cc: martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> Date: Sun, 03 May 2009 01:39:30 +0300 In-Reply-To: <878wlfk9lm.fsf@mail.jurta.org> (Juri Linkov's message of "Sat, 02 May 2009 14:48:57 +0300") Message-ID: <87y6tfdt99.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 1e897a521fdb5eac39b1f944f187ca57 X-DrWeb-checked: yes > However, when I replaced > > (funcall old-fun) > > with > > (funcall 'split-window-vertically) > > in your patch, it works perfectly in all configurations I tried. I still think `split-window-vertically' is more appropriate because in a dired buffer it should unconditionally split the original window vertically. In such situations `split-window-sensibly' is the wrong method with the wrong technique It displays a new window in the wrong place at the wrong time For the wrong reason and the wrong rhyme On the wrong day of the wrong week Wrong Wrong -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 03 May 2009 08:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124133716826580 (code B ref 1806); Sun, 03 May 2009 08:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 3 May 2009 07:52:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n437qg8Q026566 for <1806@emacsbugs.donarmstrong.com>; Sun, 3 May 2009 00:52:43 -0700 Received: (qmail invoked by alias); 03 May 2009 07:52:36 -0000 Received: from 62-47-39-208.adsl.highway.telekom.at (EHLO [62.47.39.208]) [62.47.39.208] by mail.gmx.net (mp032) with SMTP; 03 May 2009 09:52:36 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18NDslP87gNtpYXzGDQzfBdmHaLLdJwz3XlRNXszd GUdEqpuqRPjHlH Message-ID: <49FD4CD9.8060907@gmx.at> Date: Sun, 03 May 2009 09:50:49 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <87y6tfdt99.fsf@mail.jurta.org> In-Reply-To: <87y6tfdt99.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 > I still think `split-window-vertically' is more appropriate because > in a dired buffer it should unconditionally split the original window > vertically. In such situations `split-window-sensibly' is > the wrong method > with the wrong technique > > It displays a new window > in the wrong place > at the wrong time > > For the wrong reason and > the wrong rhyme > > On the wrong day of > the wrong week > > Wrong > > Wrong Kto-to majskij prazdnik otmechajet ;-) BTW, here we call a bridge day "Fenstertag" (window day) and since we didn't have any bridge day this week it _was_ the wrong day of the wrong week indeed ... I don't have any problems hard-coding `split-window-vertically' in `dired-pop-to-buffer' but: (1) `split-window-sensibly' with `split-width-threshold' nil _should_ do `split-window-vertically' in the first place. If it doesn't, I have a bug somewhere and must fix that. (2) Someone might want `split-window-sensibly' do something special for dired buffers. So please try to debug this and tell me why it doesn't split the window vertically with a dired-window-only-frame configuration in the first attempt. It DTRT here for me. martin PS: It does not DTRT when there's another window below because it does not restore the original window layout when the temporary window is closed. But that's another story ... From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 03 May 2009 12:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124135147232342 (code B ref 1806); Sun, 03 May 2009 12:00:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 3 May 2009 11:51:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n43Bp7fq032336 for <1806@emacsbugs.donarmstrong.com>; Sun, 3 May 2009 04:51:09 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M0aDq-000FfD-AC; Sun, 03 May 2009 14:51:06 +0300 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <87y6tfdt99.fsf@mail.jurta.org> <49FD4CD9.8060907@gmx.at> Date: Sun, 03 May 2009 14:46:15 +0300 In-Reply-To: <49FD4CD9.8060907@gmx.at> (martin rudalics's message of "Sun, 03 May 2009 09:50:49 +0200") Message-ID: <87ws8yquig.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 3f6c5f504711b4b2e39067d20b60c9d6 X-DrWeb-checked: yes >> Wrong >> >> Wrong > > Kto-to majskij prazdnik otmechajet ;-) > > BTW, here we call a bridge day "Fenstertag" (window day) and since we > didn't have any bridge day this week it _was_ the wrong day of the wrong > week indeed ... :-) > I don't have any problems hard-coding `split-window-vertically' in > `dired-pop-to-buffer' but: > > (1) `split-window-sensibly' with `split-width-threshold' nil _should_ do > `split-window-vertically' in the first place. If it doesn't, I have > a bug somewhere and must fix that. > > (2) Someone might want `split-window-sensibly' do something special for > dired buffers. > > So please try to debug this and tell me why it doesn't split the window > vertically with a dired-window-only-frame configuration in the first > attempt. It DTRT here for me. I tried to debug this. With your latest patch it works correctly with a dired-window-only-frame configuration, but fails when there are two horizontally split side-by-side windows with a dired buffer in one of them. It displays a list of dired files at the top of another side window. split-window-sensibly has three `or' branches: 1. Split window vertically. In my case this branch is not selected because my window-height (79) is less than split-height-threshold (80). 2. Split window horizontally. This branch is not selected since dired-pop-to-buffer sets split-width-threshold to nil (this is ok). 3. If the selected window is the only window on its frame and is not the minibuffer window, try to split it vertically. This branch is not selected since the dired buffer's window is not the only window on its frame. So display-buffer displays a list of dired files in the existing side window. I see one way to fix this - it is necessary to force the first branch to be selected. It works when I tried the following lambda in dired-pop-to-buffer: (lambda () (let ((split-height-threshold 0) (split-width-threshold nil)) (with-selected-window old-window (funcall old-fun)))) Setting split-height-threshold to 0 forces the vertical splitting. Setting split-width-threshold to nil prevents the horizontal splitting when the vertical splitting is not possible (the window is not splittable). -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 03 May 2009 19:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124137745530978 (code B ref 1806); Sun, 03 May 2009 19:10:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 3 May 2009 19:04:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n43J4AeN030969 for <1806@emacsbugs.donarmstrong.com>; Sun, 3 May 2009 12:04:12 -0700 Received: (qmail invoked by alias); 03 May 2009 19:04:03 -0000 Received: from 62-47-62-103.adsl.highway.telekom.at (EHLO [62.47.62.103]) [62.47.62.103] by mail.gmx.net (mp061) with SMTP; 03 May 2009 21:04:03 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19xNcU6HsFxgQm3IzXOmkivkkWo/cuOA1mVKPOTwZ XlYNMbnqR5BHtE Message-ID: <49FDEA44.3030409@gmx.at> Date: Sun, 03 May 2009 21:02:28 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <878wlfk9lm.fsf@mail.jurta.org> <87y6tfdt99.fsf@mail.jurta.org> <49FD4CD9.8060907@gmx.at> <87ws8yquig.fsf@mail.jurta.org> In-Reply-To: <87ws8yquig.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 > 1. Split window vertically. > > In my case this branch is not selected because my window-height (79) > is less than split-height-threshold (80). On my display this amounts to setting `split-height-threshold' nil. > So display-buffer displays a list of dired files in the existing > side window. > > I see one way to fix this - it is necessary to force > the first branch to be selected. It works when I tried > the following lambda in dired-pop-to-buffer: > > (lambda () > (let ((split-height-threshold 0) > (split-width-threshold nil)) > (with-selected-window old-window (funcall old-fun)))) > > Setting split-height-threshold to 0 forces the vertical splitting. > Setting split-width-threshold to nil prevents the horizontal splitting > when the vertical splitting is not possible (the window is not splittable). You convinced me. Thanks, martin. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 04 May 2009 13:55:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12414451593462 (code B ref 1806); Mon, 04 May 2009 13:55:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 4 May 2009 13:52:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n44DqYwX003451 for <1806@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 06:52:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FAGeP/knO+IYe/2dsb2JhbACBUMwBg30FhUk X-IronPort-AV: E=Sophos;i="4.40,292,1238990400"; d="scan'208";a="37953479" Received: from 206-248-134-30.dsl.teksavvy.com (HELO pastel.home) ([206.248.134.30]) by ironport2-out.teksavvy.com with ESMTP; 04 May 2009 09:52:28 -0400 Received: by pastel.home (Postfix, from userid 20848) id AB1ED7FDC; Mon, 4 May 2009 09:52:28 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <49FBEF5A.7080607@gmx.at> Date: Mon, 04 May 2009 09:52:28 -0400 In-Reply-To: <49FBEF5A.7080607@gmx.at> (martin rudalics's message of "Sat, 02 May 2009 08:59:38 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Closures are (should be) bread&butter; not "advanced". >>> `lexical-let' doesn't even indent reasonably :-( >> I don't know of any such bug, so please give details. > It won't indent correctly from scratch. I do have to load the CL > library first which hardly qualifies as bread&butter ;-) `lexical-let' is specific to Emacs. Closures are not. `lexical-let' is a hack. Closures are not. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 04 May 2009 16:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124145535522964 (code B ref 1806); Mon, 04 May 2009 16:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 4 May 2009 16:42:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n44GgUCk022952 for <1806@emacsbugs.donarmstrong.com>; Mon, 4 May 2009 09:42:32 -0700 Received: (qmail invoked by alias); 04 May 2009 16:42:24 -0000 Received: from 62-47-50-143.adsl.highway.telekom.at (EHLO [62.47.50.143]) [62.47.50.143] by mail.gmx.net (mp071) with SMTP; 04 May 2009 18:42:24 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19aSz4Xj3Nady1BSLWckgA4gqMU2j4x5swxpcnk4o L6Rv3b26rLYqZz Message-ID: <49FF1A94.9070708@gmx.at> Date: Mon, 04 May 2009 18:40:52 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49F969F9.5010603@gmx.at> <49FAC921.5010201@gmx.at> <49FBEF5A.7080607@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 > `lexical-let' is specific to Emacs. Closures are not. > `lexical-let' is a hack. Closures are not. That's precisely what I had in mind but was afraid to say. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 05 May 2009 07:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124150725213178 (code B ref 1806); Tue, 05 May 2009 07:15:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 5 May 2009 07:07:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER,MIXEDBDN, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n4577RNU013168 for <1806@emacsbugs.donarmstrong.com>; Tue, 5 May 2009 00:07:28 -0700 Received: (qmail invoked by alias); 05 May 2009 07:07:21 -0000 Received: from 62-47-49-59.adsl.highway.telekom.at (EHLO [62.47.49.59]) [62.47.49.59] by mail.gmx.net (mp019) with SMTP; 05 May 2009 09:07:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18eqUM6XKQeiTk+nAgkGaK6YLDorjrtRuAwDSaSy3 3+SO60tQPJRWj5 Message-ID: <49FFE515.4020608@gmx.at> Date: Tue, 05 May 2009 09:04:53 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba4qh1b.fsf@jurta.org> <496483A8.8010805@gmx.at> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000107020000010606050601" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76,0.6 This is a multi-part message in MIME format. --------------000107020000010606050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> `dired-pop-to-buffer' could bind `split-window-preferred-function' to a >> function that tries to always split the selected window instead of >> whatever window was chosen by `display-buffer' but that would override >> any user customizations of `split-window-preferred-function'. > > Why would it override it? It would of course bind > split-window-preferred-function to a function that selects the right > window and then calls the previous value. As a matter of fact, we do have to override the users' customizations here just as Juri suggested earlier. Suppose a user has set `split-window-preferred-function' to the standard option "horizontally" which always splits a window horizontally. Then `dired-pop-to-buffer' simply cannot get a vertical split when it calls the original `split-window-preferred-function'. So we probably have to do this as in the attached patch :-( martin --------------000107020000010606050601 Content-Type: text/plain; name="dired.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dired.el.diff" *** dired.el.~1.422.~ 2009-04-18 08:32:56.546875000 +0200 --- dired.el 2009-05-05 09:00:38.609375000 +0200 *************** *** 2686,2693 **** (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! ;; Don't split window horizontally. (Bug#1806) ! (let (split-width-threshold) (pop-to-buffer (get-buffer-create buf))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit --- 2686,2697 ---- (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." ! (let ((split-window-preferred-function ! (lambda (window) ! ;; Split window vertically and deliberately ignore the WINDOW ! ;; argument of `split-window-preferred-function' so the ! ;; selected window gets split instead (Bug#1806). ! (split-window-vertically)))) (pop-to-buffer (get-buffer-create buf))) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit --------------000107020000010606050601-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 17 May 2009 20:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124259107223992 (code B ref 1806); Sun, 17 May 2009 20:15:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 17 May 2009 20:11:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4HKB4xm023983 for <1806@emacsbugs.donarmstrong.com>; Sun, 17 May 2009 13:11:06 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M5mhL-000LiL-AT; Sun, 17 May 2009 23:11:03 +0300 From: Juri Linkov To: martin rudalics Cc: Stefan Monnier , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> Date: Sun, 17 May 2009 22:54:45 +0300 In-Reply-To: <49FFE515.4020608@gmx.at> (martin rudalics's message of "Tue, 05 May 2009 09:04:53 +0200") Message-ID: <87vdnzpks0.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: dd5701c86360acb8383b46d8fd27d5ab X-DrWeb-checked: yes > As a matter of fact, we do have to override the users' customizations > here just as Juri suggested earlier. Suppose a user has set > `split-window-preferred-function' to the standard option "horizontally" > which always splits a window horizontally. Then `dired-pop-to-buffer' > simply cannot get a vertical split when it calls the original > `split-window-preferred-function'. Thank you! Could you also fix Proced and Calendar? -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 08:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124263438429874 (code B ref 1806); Mon, 18 May 2009 08:20:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 08:13:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER,MIXEDBDN, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n4I8Cx73029856 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 01:13:00 -0700 Received: (qmail invoked by alias); 18 May 2009 08:12:52 -0000 Received: from 62-47-57-103.adsl.highway.telekom.at (EHLO [62.47.57.103]) [62.47.57.103] by mail.gmx.net (mp036) with SMTP; 18 May 2009 10:12:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+Pm3QNM22Pi3ttlz7TF6yqi6ABf1XPWhuBz5qnHj P8aL4h5j9fp2dk Message-ID: <4A11184A.1020805@gmx.at> Date: Mon, 18 May 2009 10:11:54 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org, Roland Winkler References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> In-Reply-To: <87vdnzpks0.fsf@mail.jurta.org> Content-Type: multipart/mixed; boundary="------------020000040001000803060702" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78,0.55 This is a multi-part message in MIME format. --------------020000040001000803060702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Could you also fix Proced and Calendar? I attached a similar patch for `proced-send-signal'. I don't know what to do about `proced' itself. Roland what do you think? martin --------------020000040001000803060702 Content-Type: text/plain; name="proced.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proced.el.diff" *** proced.el.~1.36.~ 2009-04-21 07:18:50.000000000 +0200 --- proced.el 2009-05-18 10:01:50.031250000 +0200 *************** *** 1720,1728 **** (dolist (process process-alist) (insert " " (cdr process) "\n")) (save-window-excursion ! ;; Analogous to `dired-pop-to-buffer' ! ;; Don't split window horizontally. (Bug#1806) ! (let (split-width-threshold) (pop-to-buffer (current-buffer))) (fit-window-to-buffer (get-buffer-window) nil 1) (let* ((completion-ignore-case t) --- 1720,1735 ---- (dolist (process process-alist) (insert " " (cdr process) "\n")) (save-window-excursion ! ;; Analogous to `dired-pop-to-buffer'. ! (let ((split-window-preferred-function ! (lambda (window) ! (or (and (let ((split-height-threshold 0)) ! (window-splittable-p (selected-window))) ! ;; Try to split the selected window vertically if ! ;; that's possible. (Bug#1806) ! (split-window-vertically)) ! ;; Otherwise, try to split WINDOW sensibly. ! (split-window-sensibly window))))) (pop-to-buffer (current-buffer))) (fit-window-to-buffer (get-buffer-window) nil 1) (let* ((completion-ignore-case t) --------------020000040001000803060702-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 08:20:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124263438529879 (code B ref 1806); Mon, 18 May 2009 08:20:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 08:13:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER,MIXEDBDN, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n4I8D1Nt029858 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 01:13:02 -0700 Received: (qmail invoked by alias); 18 May 2009 08:12:55 -0000 Received: from 62-47-57-103.adsl.highway.telekom.at (EHLO [62.47.57.103]) [62.47.57.103] by mail.gmx.net (mp018) with SMTP; 18 May 2009 10:12:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18IOaRiUqMIDZ7SxYXEKDTyhRTXSVFIB6qomH40M3 XgHVmsHRUHzbs/ Message-ID: <4A11184F.4030606@gmx.at> Date: Mon, 18 May 2009 10:11:59 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org, Glenn Morris References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> In-Reply-To: <87vdnzpks0.fsf@mail.jurta.org> Content-Type: multipart/mixed; boundary="------------020402040707080502080803" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73,0.65 This is a multi-part message in MIME format. --------------020402040707080502080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Could you also fix Proced and Calendar? I suppose you mean the call in `calendar-basic-setup' here. In this case you probably want to split the largest or LRU window vertically even if your customized settings would imply a horizontal split. But you don't insist on splitting the selected window. Right? Any opinions, Glenn? martin --------------020402040707080502080803 Content-Type: text/plain; name="calendar.el.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="calendar.el.diff" *** calendar.el.~1.281.~ 2009-03-16 07:35:28.000000000 +0100 --- calendar.el 2009-05-18 09:52:53.203125000 +0200 *************** *** 1291,1297 **** (calendar-increment-month month year (- calendar-offset)) ;; Display the buffer before calling calendar-generate-window so that it ;; can get a chance to adjust the window sizes to the frame size. ! (or nodisplay (pop-to-buffer calendar-buffer)) (calendar-generate-window month year) (if (and calendar-view-diary-initially-flag (calendar-date-is-visible-p date)) --- 1291,1301 ---- (calendar-increment-month month year (- calendar-offset)) ;; Display the buffer before calling calendar-generate-window so that it ;; can get a chance to adjust the window sizes to the frame size. ! (or nodisplay ! (let ((split-height-threshold 0) ! split-width-threshold) ! ;; Prefer vertical splits (Bug#1806). ! (pop-to-buffer calendar-buffer))) (calendar-generate-window month year) (if (and calendar-view-diary-initially-flag (calendar-date-is-visible-p date)) --------------020402040707080502080803-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: "Roland Winkler" , 1806@debbugs.gnu.org Resent-From: "Roland Winkler" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 11:05:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124264440310728 (code B ref 1806); Mon, 18 May 2009 11:05:08 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 11:00:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from tfkpsv.physik.uni-erlangen.de (tfkpsv.physik.uni-erlangen.de [131.188.164.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IAxwGu010676 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 04:00:00 -0700 Received: from tfkp07.physik.uni-erlangen.de (tfkp07.physik.uni-erlangen.de [131.188.164.207]) by tfkpsv.physik.uni-erlangen.de (Postfix) with ESMTP id ED84620CC8; Mon, 18 May 2009 12:59:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> Date: Mon, 18 May 2009 12:59:48 +0200 From: "Roland Winkler" To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org In-Reply-To: <4A11184A.1020805@gmx.at> References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184A.1020805@gmx.at> X-Mailer: VM 8.0.9 under Emacs 22.2.1 (i686-pc-linux-gnu) On Mon May 18 2009 martin rudalics wrote: > > Could you also fix Proced and Calendar? > > I attached a similar patch for `proced-send-signal'. I don't know what > to do about `proced' itself. Roland what do you think? What do you mean by "proced itself"? Only proced-send-signal should behave analogous to dired-pop-to-buffer. Roland From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 12:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.1242648906744 (code B ref 1806); Mon, 18 May 2009 12:20:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 12:15:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id n4ICF01h000664 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 05:15:01 -0700 Received: (qmail invoked by alias); 18 May 2009 12:14:54 -0000 Received: from 62-47-57-103.adsl.highway.telekom.at (EHLO [62.47.57.103]) [62.47.57.103] by mail.gmx.net (mp050) with SMTP; 18 May 2009 14:14:54 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18yRERBtSAyaOxofLBlKKH/0HvsbZrbomwVma8JrB N4UYMuw20cQaZW Message-ID: <4A11513D.40403@gmx.at> Date: Mon, 18 May 2009 14:14:53 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Roland Winkler CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184A.1020805@gmx.at> <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> In-Reply-To: <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001 > What do you mean by "proced itself"? Only proced-send-signal should > behave analogous to dired-pop-to-buffer. I meant whether `proced' which uses `pop-to-buffer' has any preferences about where and how to pop up that buffer. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: "Roland Winkler" , 1806@debbugs.gnu.org Resent-From: "Roland Winkler" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 15:10:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124265905716667 (code B ref 1806); Mon, 18 May 2009 15:10:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 15:04:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from tfkpsv.physik.uni-erlangen.de (tfkpsv.physik.uni-erlangen.de [131.188.164.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IF4DJL016661 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 08:04:15 -0700 Received: from tfkp07.physik.uni-erlangen.de (tfkp07.physik.uni-erlangen.de [131.188.164.207]) by tfkpsv.physik.uni-erlangen.de (Postfix) with ESMTP id 157B8224A5; Mon, 18 May 2009 17:04:08 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18961.30951.388917.452401@tfkp07.physik.uni-erlangen.de> Date: Mon, 18 May 2009 17:04:07 +0200 From: "Roland Winkler" To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org In-Reply-To: <4A11513D.40403@gmx.at> References: <87r63gzcap.fsf@jurta.org> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184A.1020805@gmx.at> <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> <4A11513D.40403@gmx.at> X-Mailer: VM 8.0.9 under Emacs 22.2.1 (i686-pc-linux-gnu) On Mon May 18 2009 martin rudalics wrote: > I meant whether `proced' which uses `pop-to-buffer' has any preferences > about where and how to pop up that buffer. I see. I have never much thought about that. If anyone has some argument why it might be better that Proced used something else instead of a simple call of pop-to-buffer, I'd be happy to use some appropriate code. Otherwise I suggest to keep it the way it is now (or wait till after the next release). Certainly, Proced is different from Dired in the sense that normally one will have only one such buffer. Roland From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 18:55:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124267256618027 (code B ref 1806); Mon, 18 May 2009 18:55:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 18:49:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-7.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IInLfu018020 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 11:49:22 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1M67tn-00083c-JF; Mon, 18 May 2009 14:49:19 -0400 From: Glenn Morris To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> X-Spook: Gazprom Commecen AFSPC government warfare COSCO Albanian X-Ran: .yc"Q{eR0^gQ2Z(|kB2Y>;icD559>{r[p0Ag@ao%hA~DNc;">0z>yEF~b,y!oj%7}"?5?% X-Hue: yellow X-Attribution: GM Date: Mon, 18 May 2009 14:49:19 -0400 In-Reply-To: <4A11184F.4030606@gmx.at> (martin rudalics's message of "Mon, 18 May 2009 10:11:59 +0200") Message-ID: <27ljouutzk.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: > I suppose you mean the call in `calendar-basic-setup' here. In this > case you probably want to split the largest or LRU window vertically > even if your customized settings would imply a horizontal split. But > you don't insist on splitting the selected window. Right? > > Any opinions, Glenn? Hi; I haven't been following this, but after a quick skim of the (long) thread, I think neither the current nor the proposed behaviour is ideal (it seems to be a choice between getting the height wrong or the width wrong), but I prefer the current one. I'd rather leave it as is for now, and look to improve it after 23.1. Thanks. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 18 May 2009 19:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12426758841646 (code B ref 1806); Mon, 18 May 2009 19:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 May 2009 19:44:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4IJichR001606 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 12:44:40 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFABdYEUpMCovv/2dsb2JhbACBT810hAEFhWo X-IronPort-AV: E=Sophos;i="4.41,211,1241409600"; d="scan'208";a="38737802" Received: from 76-10-139-239.dsl.teksavvy.com (HELO ceviche.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 15:44:25 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 6A727B4136; Mon, 18 May 2009 15:44:25 -0400 (EDT) From: Stefan Monnier To: Roland Winkler Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184A.1020805@gmx.at> <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> <4A11513D.40403@gmx.at> <18961.30951.388917.452401@tfkp07.physik.uni-erlangen.de> Date: Mon, 18 May 2009 15:44:25 -0400 In-Reply-To: <18961.30951.388917.452401@tfkp07.physik.uni-erlangen.de> (Roland Winkler's message of "Mon, 18 May 2009 17:04:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I meant whether `proced' which uses `pop-to-buffer' has any preferences >> about where and how to pop up that buffer. > I see. I have never much thought about that. If anyone has some > argument why it might be better that Proced used something else > instead of a simple call of pop-to-buffer, I'd be happy to use some > appropriate code. Otherwise I suggest to keep it the way it is now > (or wait till after the next release). Certainly, Proced is > different from Dired in the sense that normally one will have only > one such buffer. We should refrain from using anything else than just a plain `pop-to-buffer', except for those cases where it is clearly problematic. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 19 May 2009 00:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124269386723308 (code B ref 1806); Tue, 19 May 2009 00:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 May 2009 00:44:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J0iLSm023277 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 17:44:22 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M6DRM-000Lvm-3i; Tue, 19 May 2009 03:44:20 +0300 From: Juri Linkov To: "Roland Winkler" Cc: martin rudalics , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184A.1020805@gmx.at> <18961.16292.147715.230995@tfkp07.physik.uni-erlangen.de> <4A11513D.40403@gmx.at> <18961.30951.388917.452401@tfkp07.physik.uni-erlangen.de> Date: Tue, 19 May 2009 03:09:23 +0300 In-Reply-To: <18961.30951.388917.452401@tfkp07.physik.uni-erlangen.de> (Roland Winkler's message of "Mon, 18 May 2009 17:04:07 +0200") Message-ID: <87d4a6hs24.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 5389b9e13478507b5d7b23e4ed053241 X-DrWeb-checked: yes > I see. I have never much thought about that. If anyone has some > argument why it might be better that Proced used something else > instead of a simple call of pop-to-buffer, I'd be happy to use some > appropriate code. Otherwise I suggest to keep it the way it is now > (or wait till after the next release). Certainly, Proced is > different from Dired in the sense that normally one will have only > one such buffer. Indeed, with its Dired-like keybindings it is still different from Dired in regard to displaying a Proced window itself where it is more like a Buffer List (`C-x C-b'). So e.g. as it's easy to add "*Buffer List*" to `same-window-buffer-names', it's easy to add "*Proced*" as well and to do other standard customizations allowed by `pop-to-buffer'. This is unlike a non-standard treatment of displaying a window with a list of selected items to process. I think no change is needed for `pop-to-buffer' that displays a Proced window. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 19 May 2009 00:50:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124269386723313 (code B ref 1806); Tue, 19 May 2009 00:50:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 May 2009 00:44:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J0iNqR023282 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 17:44:24 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M6DRN-0000cw-Nf; Tue, 19 May 2009 03:44:21 +0300 From: Juri Linkov To: Glenn Morris Cc: martin rudalics , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> Date: Tue, 19 May 2009 03:19:45 +0300 In-Reply-To: <27ljouutzk.fsf@fencepost.gnu.org> (Glenn Morris's message of "Mon, 18 May 2009 14:49:19 -0400") Message-ID: <87y6suexzd.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 7b6940144bc5d56bdacd12344196c2df X-DrWeb-checked: yes > Hi; I haven't been following this, but after a quick skim of the > (long) thread, I think neither the current nor the proposed behaviour > is ideal (it seems to be a choice between getting the height wrong or > the width wrong), but I prefer the current one. I'd rather leave it as > is for now, and look to improve it after 23.1. Thanks. It is unfortunate that no one yet paid attention to the Calendar's treatment of the wide-screen configuration. Since now we have a new smart window splitting, it produces very bad results on such configurations - `M-x calendar' displays an ugly 70-line window instead of a narrow 7-line window that fits nicely to the contents of the Calendar buffer. That's because assumptions about the behaviour of `display-buffer' in `calendar-basic-setup' and `calendar-generate-window' are now invalid. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 19 May 2009 00:50:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124269386923318 (code B ref 1806); Tue, 19 May 2009 00:50:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 May 2009 00:44:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J0iOnC023295 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 17:44:25 -0700 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.69) (envelope-from ) id 1M6DRP-0000dd-4G; Tue, 19 May 2009 03:44:23 +0300 From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org, Glenn Morris Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87aba3qb5g.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> Date: Tue, 19 May 2009 03:18:45 +0300 In-Reply-To: <4A11184F.4030606@gmx.at> (martin rudalics's message of "Mon, 18 May 2009 10:11:59 +0200") Message-ID: <87k54eexkd.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 367251710ae6d8069d2a2bb66b314d03 X-DrWeb-checked: yes >> Could you also fix Proced and Calendar? > > I suppose you mean the call in `calendar-basic-setup' here. In this > case you probably want to split the largest or LRU window vertically > even if your customized settings would imply a horizontal split. But > you don't insist on splitting the selected window. Right? It seems a fix is not as simple. The function `calendar-generate-window' comes into play and doesn't adjust the window to fit the displayed calendar in horizontally split windows. The condition (not (window-full-width-p)) prevents calling `fit-window-to-buffer': (if (or (one-window-p t) (not (window-full-width-p))) ;; Don't mess with the window size, but ensure that the first ;; line is fully visible. (set-window-vscroll nil 0) ;; Adjust the window to exactly fit the displayed calendar. (fit-window-to-buffer nil nil calendar-minimum-window-height)) Removing (not (window-full-width-p)) fixes this, but I don't know if this change has some side effect. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 19 May 2009 02:10:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.124269860513215 (code B ref 1806); Tue, 19 May 2009 02:10:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 May 2009 02:03:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n4J23LMv013202 for <1806@emacsbugs.donarmstrong.com>; Mon, 18 May 2009 19:03:22 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAPavEUpMCovv/2dsb2JhbACBT8t9hAEFhWo X-IronPort-AV: E=Sophos;i="4.41,212,1241409600"; d="scan'208";a="38744548" Received: from 76-10-139-239.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.239]) by ironport2-out.teksavvy.com with ESMTP; 18 May 2009 22:03:15 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4B7B67F29; Mon, 18 May 2009 22:04:13 -0400 (EDT) From: Stefan Monnier To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <87k54eexkd.fsf@mail.jurta.org> Date: Mon, 18 May 2009 22:04:13 -0400 In-Reply-To: <87k54eexkd.fsf@mail.jurta.org> (Juri Linkov's message of "Tue, 19 May 2009 03:18:45 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > (if (or (one-window-p t) (not (window-full-width-p))) > ;; Don't mess with the window size, but ensure that the first > ;; line is fully visible. > (set-window-vscroll nil 0) > ;; Adjust the window to exactly fit the displayed calendar. > (fit-window-to-buffer nil nil calendar-minimum-window-height)) > Removing (not (window-full-width-p)) fixes this, but I don't know if this > change has some side effect. Often (not (window-full-width-p)) is used as a round-about and confusing way to check whether resizing is safe (in the sense that it doesn't risk deleting other windows along the way). In such cases, it is preferable to use window-safely-shrinkable-p, which is also less conservative. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 03 Oct 2009 02:30:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125453642416579 (code B ref 1806); Sat, 03 Oct 2009 02:30:11 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 3 Oct 2009 02:20:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n932KM8i016479 for <1806@emacsbugs.donarmstrong.com>; Fri, 2 Oct 2009 19:20:23 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MtuEP-0003Ta-3j; Fri, 02 Oct 2009 22:20:21 -0400 From: Glenn Morris To: 1806@debbugs.gnu.org Cc: martin rudalics , Juri Linkov References: <87r63gzcap.fsf@jurta.org> <4965AE6B.6070802@gmx.at> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> X-Spook: ammunition White Water keyhole Vince Foster strategic X-Ran: Wy[+"H"xy>c}A7u[i:8f3pMliFxE9|g]0w<`mb User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Glenn Morris wrote: > Hi; I haven't been following this, but after a quick skim of the > (long) thread, I think neither the current nor the proposed behaviour > is ideal (it seems to be a choice between getting the height wrong or > the width wrong), but I prefer the current one. I'd rather leave it as > is for now, and look to improve it after 23.1. I believe the behaviour of the calendar is now fixed in this regard. I don't know if there is anything else left to do for this lengthy bug, or if it can be closed now. The only remaining calendar issue I can see is that one might prefer the diary to always appear directly above (or below) the calendar, rather than to one side. This could be achieved by the use of windmove. I might install something along those lines, or I might not bother. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 05 Oct 2009 22:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125477970516660 (code B ref 1806); Mon, 05 Oct 2009 22:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 5 Oct 2009 21:55:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n95Lt2eP016610 for <1806@emacsbugs.donarmstrong.com>; Mon, 5 Oct 2009 14:55:04 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (82.131.99.248.cable.starman.ee [82.131.99.248]) by mx1.starman.ee (Postfix) with ESMTP id CD0183F412C; Tue, 6 Oct 2009 00:54:55 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87fxjtmo4z.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> Date: Tue, 06 Oct 2009 00:45:07 +0300 In-Reply-To: (Glenn Morris's message of "Fri, 02 Oct 2009 22:20:21 -0400") Message-ID: <87vditmrxs.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Hi; I haven't been following this, but after a quick skim of the >> (long) thread, I think neither the current nor the proposed behaviour >> is ideal (it seems to be a choice between getting the height wrong or >> the width wrong), but I prefer the current one. I'd rather leave it as >> is for now, and look to improve it after 23.1. > > I believe the behaviour of the calendar is now fixed in this regard. > I don't know if there is anything else left to do for this lengthy > bug, or if it can be closed now. Thank you. I wonder how did you test your change. In emacs -Q I see a strange window configuration after `M-x calendar RET' in a single wide window: +-------------------------+ +------------+------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | | | | *Messages* | | | | +------------+ | | | | | | *scratch* | | *scratch* | *Calendar* | +-------------------------+ +------------+------------+ I believe it was supposed to do rather: +-------------------------+ +-------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | *scratch* | | | +-------------------------+ | | | | | *scratch* | | *Calendar* | +-------------------------+ +-------------------------+ i.e. the calendar to always appear directly below from the current window. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stephen Berman , 1806@debbugs.gnu.org Resent-From: Stephen Berman Original-Sender: steve@escher.local.home Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 05 Oct 2009 22:35:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125478168322840 (code B ref 1806); Mon, 05 Oct 2009 22:35:08 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 5 Oct 2009 22:28:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n95MS0m1022833 for <1806@emacsbugs.donarmstrong.com>; Mon, 5 Oct 2009 15:28:02 -0700 Received: (qmail invoked by alias); 05 Oct 2009 22:27:54 -0000 Received: from i59F57519.versanet.de (EHLO escher.local.home) [89.245.117.25] by mail.gmx.net (mp006) with SMTP; 06 Oct 2009 00:27:54 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1/NZCgjUT/NUCdUmxfEVvgwBeowjVVpHbNNKzXkrs XfH5K53wJ2RWa2 Received: by escher.local.home (Postfix, from userid 1000) id 6A1621D1955; Tue, 6 Oct 2009 00:27:53 +0200 (CEST) From: Stephen Berman To: Juri Linkov Cc: 1806@debbugs.gnu.org, Glenn Morris References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> Sender: steve@escher.local.home Date: Tue, 06 Oct 2009 00:27:53 +0200 In-Reply-To: <87vditmrxs.fsf@mail.jurta.org> (Juri Linkov's message of "Tue, 06 Oct 2009 00:45:07 +0300") Message-ID: <87ocol1no6.fsf@escher.local.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 On Tue, 06 Oct 2009 00:45:07 +0300 Juri Linkov wrote: >>> Hi; I haven't been following this, but after a quick skim of the >>> (long) thread, I think neither the current nor the proposed behaviour >>> is ideal (it seems to be a choice between getting the height wrong or >>> the width wrong), but I prefer the current one. I'd rather leave it as >>> is for now, and look to improve it after 23.1. >> >> I believe the behaviour of the calendar is now fixed in this regard. >> I don't know if there is anything else left to do for this lengthy >> bug, or if it can be closed now. > > Thank you. I wonder how did you test your change. In emacs -Q > I see a strange window configuration after `M-x calendar RET' > in a single wide window: > > +-------------------------+ +------------+------------+ > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | ===> | | | > | | | | | > | | | | *Messages* | > | | | +------------+ > | | | | | > | *scratch* | | *scratch* | *Calendar* | > +-------------------------+ +------------+------------+ > > I believe it was supposed to do rather: > > +-------------------------+ +-------------------------+ > | | | | > | | | | > | | | | > | | | | > | | | | > | | | | > | | ===> | | > | | | | > | | | *scratch* | > | | +-------------------------+ > | | | | > | *scratch* | | *Calendar* | > +-------------------------+ +-------------------------+ > > i.e. the calendar to always appear directly below from the current window. I also see this. What's more, I have things configured so that calling Calendar also pops up the fancy diary display, and starting with a single (screen-) wide window, the result is similar to the above, namely: +-------------------------+ +------------+------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | | | | *Messages* | | | | +------------+ | | | | | | *scratch* | | Diary | *Calendar* | +-------------------------+ +------------+------------+ (Note that in the result *scratch* is not displayed in the frame, but instead the previous buffer *Messages*.) Steve Berman From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 03:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125479757328864 (code B ref 1806); Tue, 06 Oct 2009 03:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 02:52:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n962qpc1028861 for <1806@emacsbugs.donarmstrong.com>; Mon, 5 Oct 2009 19:52:53 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mv0AU-0002Qv-NF; Mon, 05 Oct 2009 22:52:50 -0400 From: Glenn Morris To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics References: <87r63gzcap.fsf@jurta.org> <49671922.4080609@gmx.at> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> X-Spook: AVIP FSF military CDC Honduras RSA CIA Delta Force X-Ran: ^h3Oj@Tr#GKt,NQcOdD]v;-%(mL`T[97kL1@(TiC$Cr*3N&5a#jy}&'XYZ~tJ]*@T\e1&L X-Hue: magenta X-Attribution: GM Date: Mon, 05 Oct 2009 22:52:50 -0400 Message-ID: <78zl8544jh.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Juri Linkov wrote: > In emacs -Q I see a strange window configuration after `M-x calendar > RET' in a single wide window: > > +-------------------------+ +------------+------------+ > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | ===> | | | > | | | | | > | | | | *Messages* | > | | | +------------+ > | | | | | > | *scratch* | | *scratch* | *Calendar* | > +-------------------------+ +------------+------------+ That was the intended behaviour. If the frame is wide enough to split horizontally, it is split horizontally. This both makes sense and looks correct to me. > I believe it was supposed to do rather: > > +-------------------------+ +-------------------------+ > | | | | > | | | | > | | | | > | | | | > | | | | > | | | | > | | ===> | | > | | | | > | | | *scratch* | > | | +-------------------------+ > | | | | > | *scratch* | | *Calendar* | > +-------------------------+ +-------------------------+ It will do this if the frame is not wider than split-width-threshold. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 03:00:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125479758428871 (code B ref 1806); Tue, 06 Oct 2009 03:00:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 02:53:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n962r21E028868 for <1806@emacsbugs.donarmstrong.com>; Mon, 5 Oct 2009 19:53:04 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mv0Ag-0002RO-FO; Mon, 05 Oct 2009 22:53:02 -0400 From: Glenn Morris To: Stephen Berman Cc: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <87ocol1no6.fsf@escher.local.home> X-Spook: SWAT CDMA bank MILSATCOM Cocaine Albanian Mossad X-Ran: Z40>M/+Z74Q:1Tm@,(CQ#b.r8K`J$z4:n\f#nv#Ap&RCOGY$#[mSCZ4`iV6p7Ix:.eRYb< X-Hue: magenta X-Attribution: GM Date: Mon, 05 Oct 2009 22:53:02 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Stephen Berman wrote: > What's more, I have things configured so that calling Calendar also > pops up the fancy diary display, and starting with a single > (screen-) wide window, the result is similar to the above, namely: > > +-------------------------+ +------------+------------+ > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | > | | ===> | | | > | | | | | > | | | | *Messages* | > | | | +------------+ > | | | | | > | *scratch* | | Diary | *Calendar* | > +-------------------------+ +------------+------------+ As I wrote: The only remaining calendar issue I can see is that one might prefer the diary to always appear directly above (or below) the calendar, rather than to one side. This could be achieved by the use of windmove. I might install something along those lines, or I might not bother. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 04:05:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12548013286429 (code B ref 1806); Tue, 06 Oct 2009 04:05:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 03:55:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n963tQlL006421 for <1806@emacsbugs.donarmstrong.com>; Mon, 5 Oct 2009 20:55:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAK5cykrO+KK+/2dsb2JhbACBUtEthCoEhyc X-IronPort-AV: E=Sophos;i="4.44,510,1249272000"; d="scan'208";a="47151554" Received: from 206-248-162-190.dsl.teksavvy.com (HELO ceviche.home) ([206.248.162.190]) by ironport2-out.pppoe.ca with ESMTP; 05 Oct 2009 23:55:20 -0400 Received: by ceviche.home (Postfix, from userid 20848) id A45AEB4190; Mon, 5 Oct 2009 23:55:19 -0400 (EDT) From: Stefan Monnier To: Glenn Morris Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: References: <87r63gzcap.fsf@jurta.org> <87zlhubw10.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> Date: Mon, 05 Oct 2009 23:55:19 -0400 In-Reply-To: <78zl8544jh.fsf@fencepost.gnu.org> (Glenn Morris's message of "Mon, 05 Oct 2009 22:52:50 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> +-------------------------+ +------------+------------+ >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | ===> | | | >> | | | | | >> | | | | *Messages* | >> | | | +------------+ >> | | | | | >> | *scratch* | | *scratch* | *Calendar* | >> +-------------------------+ +------------+------------+ > That was the intended behaviour. If the frame is wide enough to split > horizontally, it is split horizontally. This both makes sense and > looks correct to me. Showing *Messages* out of the blue is definitely not a feature. IOW It doesn't look correct to me. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 07:30:31 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12548137365915 (code B ref 1806); Tue, 06 Oct 2009 07:30:31 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 07:22:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n967MCYQ005911 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 00:22:13 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Mv4N9-00047N-4B; Tue, 06 Oct 2009 03:22:11 -0400 From: Glenn Morris To: Stefan Monnier Cc: 1806@debbugs.gnu.org, Juri Linkov References: <87r63gzcap.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> X-Spook: BLU-97 A/B oil COSCO ASIO codes UMTS ASO ANC X-Ran: qs7P}OK-L*,DI['7+za^1f=Nl51wM8,MXWryF`ULe;:Pg<6+1)y*d$w\2T+4lf8pTN{nA{ X-Hue: white X-Attribution: GM Date: Tue, 06 Oct 2009 03:22:11 -0400 In-Reply-To: (Stefan Monnier's message of "Mon, 05 Oct 2009 23:55:19 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Stefan Monnier wrote: > Showing *Messages* out of the blue is definitely not a feature. > IOW It doesn't look correct to me. It's because: ----------- | scratch | | | | | ----------- goes to : ------------------ | scratch | other | | | ------ | | cal | ------------------ where `other' is whatever other-buffer returns. It's not choosing messages specially, but obviously in emacs -Q there are no other buffers available. Then if you show the diary, it may happen to put it in the leftmost window, replacing scratch. AFAIK there are no general Emacs window-handling features to do any of this in any more sophisticated fashion. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stephen Berman , 1806@debbugs.gnu.org Resent-From: Stephen Berman Original-Sender: steve@escher.local.home Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 08:25:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125481707914517 (code B ref 1806); Tue, 06 Oct 2009 08:25:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 08:17:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n968Hua9014514 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 01:17:58 -0700 Received: (qmail invoked by alias); 06 Oct 2009 08:17:50 -0000 Received: from i59F56E8B.versanet.de (EHLO escher.local.home) [89.245.110.139] by mail.gmx.net (mp023) with SMTP; 06 Oct 2009 10:17:50 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1/sHWISZfHsOaq3/u1RGa1mF+Uhc3s3scCfn16QWC HzffctM1Tu1b2n Received: by escher.local.home (Postfix, from userid 1000) id D95A01D1955; Tue, 6 Oct 2009 10:17:48 +0200 (CEST) From: Stephen Berman To: Glenn Morris Cc: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <87ocol1no6.fsf@escher.local.home> Sender: steve@escher.local.home Date: Tue, 06 Oct 2009 10:17:48 +0200 In-Reply-To: (Glenn Morris's message of "Mon, 05 Oct 2009 22:53:02 -0400") Message-ID: <87pr917x77.fsf@escher.local.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 On Mon, 05 Oct 2009 22:53:02 -0400 Glenn Morris wrote: > Stephen Berman wrote: > >> What's more, I have things configured so that calling Calendar also >> pops up the fancy diary display, and starting with a single >> (screen-) wide window, the result is similar to the above, namely: >> >> +-------------------------+ +------------+------------+ >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | ===> | | | >> | | | | | >> | | | | *Messages* | >> | | | +------------+ >> | | | | | >> | *scratch* | | Diary | *Calendar* | >> +-------------------------+ +------------+------------+ > > As I wrote: > > The only remaining calendar issue I can see is that one might > prefer the diary to always appear directly above (or below) the > calendar, rather than to one side. This could be achieved by the > use of windmove. I might install something along those lines, or I > might not bother. Oh yeah, sorry, I forgot about that. Steve Berman From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 08:25:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125481717214531 (code B ref 1806); Tue, 06 Oct 2009 08:25:09 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 08:19:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n968JUYS014526 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 01:19:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMuaykrO+KK+/2dsb2JhbACBUdFghCoEhyc X-IronPort-AV: E=Sophos;i="4.44,511,1249272000"; d="scan'208";a="47155220" Received: from 206-248-162-190.dsl.teksavvy.com (HELO ceviche.home) ([206.248.162.190]) by ironport2-out.pppoe.ca with ESMTP; 06 Oct 2009 04:19:25 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 1C5B9B4190; Tue, 6 Oct 2009 04:19:25 -0400 (EDT) From: Stefan Monnier To: Glenn Morris Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: References: <87r63gzcap.fsf@jurta.org> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> Date: Tue, 06 Oct 2009 04:19:24 -0400 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 03:22:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> Showing *Messages* out of the blue is definitely not a feature. >> IOW It doesn't look correct to me. > It's b=E9casse: [..] > AFAIK there are no general Emacs window-handling features to do any of > this in any more sophisticated fashion. I know why the code gives this result. But still, result is not good. I think it's better to end up with +----------------------------------------------------------+ | | | | | *scratch* | | | +----------------------------------------------------------+ | | | | | *calendar* | | | +----------------------------------------------------------+ It may be suboptimal, but at least it doesn't end up with a weird window arrangement displaying some randomly chosen old buffer. It's easy for the user to hit C-x 3 before running calendar, if she doesn't like this behavior; much easier than trying to fix the mess of the current code, when you're not happy with its choices. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 09:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125481940719878 (code B ref 1806); Tue, 06 Oct 2009 09:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 08:56:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n968uj3T019873 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 01:56:46 -0700 Received: (qmail invoked by alias); 06 Oct 2009 08:56:39 -0000 Received: from 62-47-35-176.adsl.highway.telekom.at (EHLO [62.47.35.176]) [62.47.35.176] by mail.gmx.net (mp070) with SMTP; 06 Oct 2009 10:56:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/WWVdkErzWMajAEgdZ06/mO0GzWagAULI1+vJBXL c6E0pu4bnHjjrE Message-ID: <4ACB0646.5030102@gmx.at> Date: Tue, 06 Oct 2009 10:56:38 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Glenn Morris , 1806@debbugs.gnu.org CC: Stefan Monnier References: <87r63gzcap.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 > It's because: > > ----------- > | scratch | > | | > | | > ----------- > > goes to : > > ------------------ > | scratch | other | > | | ------ > | | cal | > ------------------ > > where `other' is whatever other-buffer returns. It's not choosing > messages specially, but obviously in emacs -Q there are no other > buffers available. It could show *scratch* twice. Ideally, the "other" window would not be created but a "vertical" calendar layout used instead ;-) Or show all months of the respective year (maybe in some dimmed face) to make use of the available space. With the current layout I don't see much sense doing a horizontal split at all. > Then if you show the diary, it may happen to put it in the leftmost > window, replacing scratch. > > AFAIK there are no general Emacs window-handling features to do any of > this in any more sophisticated fashion. We could supply a command to show diary and cal simultaneously in two windows above each other. Otherwise, we could remember in a separate variable which "other" window was created when the calendar window was split off and, if that other window is still alive and the calendar window is below or on the right of it, use it for displaying the diary. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 16:25:12 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125484596227765 (code B ref 1806); Tue, 06 Oct 2009 16:25:12 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 16:19:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96GJLPL027752 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 09:19:22 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MvCky-0003Pr-8N; Tue, 06 Oct 2009 12:19:20 -0400 From: Glenn Morris To: martin rudalics Cc: 1806@debbugs.gnu.org, Stefan Monnier References: <87r63gzcap.fsf@jurta.org> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> X-Spook: CIDA nuclear JSOFC3IP MD2 clandestine Kosovo FTS2000 X-Ran: XikgN1f"asK,[ZTMty%n!nh\jjH?`R!C9V}oFfOZtP=Ai3s`rJ]qx4|b4/$OCX9EQ}+4IL X-Hue: yellow X-Attribution: GM Date: Tue, 06 Oct 2009 12:19:20 -0400 In-Reply-To: <4ACB0646.5030102@gmx.at> (martin rudalics's message of "Tue, 06 Oct 2009 10:56:38 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: > It could show *scratch* twice. Yes, it could, easily. > Ideally, the "other" window would not be created but a "vertical" > calendar layout used instead ;-) Or show all months of the > respective year (maybe in some dimmed face) to make use of the > available space. This is something I would like to see, but it is a lot of work. > With the current layout I don't see much sense doing a horizontal > split at all. Because it makes zero sense to have a calendar wider than 80 columns. The space is always wasted. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 16:55:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125484759332323 (code B ref 1806); Tue, 06 Oct 2009 16:55:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 16:46:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96GkUpf032318 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 09:46:32 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n96GkUm1000854; Tue, 6 Oct 2009 12:46:30 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id B72359008D; Tue, 6 Oct 2009 12:46:29 -0400 (EDT) From: Stefan Monnier To: Glenn Morris Cc: martin rudalics , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> Date: Tue, 06 Oct 2009 12:46:29 -0400 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 12:19:20 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3378=0 > Because it makes zero sense to have a calendar wider than 80 columns. But it doesn't harm either. > The space is always wasted. But it can be recovered by a simple C-x 2. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 18:35:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125485361917007 (code B ref 1806); Tue, 06 Oct 2009 18:35:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 18:26:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96IQv3I017004 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 11:26:58 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MvEkS-0004RO-Nd; Tue, 06 Oct 2009 14:26:56 -0400 From: Glenn Morris To: martin rudalics Cc: 1806@debbugs.gnu.org, Stefan Monnier References: <87r63gzcap.fsf@jurta.org> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> X-Spook: BCCI AVN Echelon passwd ICE Skipjack Chobetsu Rubin X-Ran: 3i.O9[qpWD-j|''Ud53mhL+ygpMx'FuF;N?yeddS}B!u;49k6"V]B.#U&L4-_^zKeeIYgr X-Hue: cyan X-Attribution: GM Date: Tue, 06 Oct 2009 14:26:56 -0400 In-Reply-To: <4ACB0646.5030102@gmx.at> (martin rudalics's message of "Tue, 06 Oct 2009 10:56:38 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: > We could supply a command to show diary and cal simultaneously in two > windows above each other. (setq calendar-setup 'one-frame) From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 22:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125486893927803 (code B ref 1806); Tue, 06 Oct 2009 22:50:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 22:42:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96MgHav027799 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 15:42:18 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (62.65.209.67.cable.starman.ee [62.65.209.67]) by mx1.starman.ee (Postfix) with ESMTP id 03D0A3F41B1; Wed, 7 Oct 2009 01:42:09 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> Date: Wed, 07 Oct 2009 01:38:43 +0300 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 14:26:56 -0400") Message-ID: <87pr909mh8.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> We could supply a command to show diary and cal simultaneously in two >> windows above each other. > > (setq calendar-setup 'one-frame) Exactly. When `calendar-setup' is configured to display the calendar in a separate frame and the frame is wide, we don't try filling the available space with random buffers. A single-frame configuration should not be different from this. A wide-screen single-frame configuration is a special case. At least, I perceive `C-x 3' as a way to create a virtual two-frame configuration with two side-by-side frame-like windows. Consequently, I expect `M-x calendar' respecting my choice: either keeping the single frame and displaying the calendar below the current buffer, or when I create a virtual two-frame configuration with `C-x 3' then keeping this configuration intact and displaying the calendar below the current buffer. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 22:50:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125486893927808 (code B ref 1806); Tue, 06 Oct 2009 22:50:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 22:42:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,SARE_BAYES_5x7,SARE_BAYES_6x7 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96MgH2q027800 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 15:42:18 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (62.65.209.67.cable.starman.ee [62.65.209.67]) by mx1.starman.ee (Postfix) with ESMTP id 6EFCA3F415F; Wed, 7 Oct 2009 01:42:09 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> Date: Wed, 07 Oct 2009 01:38:40 +0300 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 12:19:20 -0400") Message-ID: <87r5tg9mhb.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> It could show *scratch* twice. > > Yes, it could, easily. Please don't duplicate buffers without users' consent. >> Ideally, the "other" window would not be created but a "vertical" >> calendar layout used instead ;-) Or show all months of the >> respective year (maybe in some dimmed face) to make use of the >> available space. > > This is something I would like to see, but it is a lot of work. Yes, this would be ideal by either displaying the full year: +-------------------------+-------------------------+ | | Jan2009 Feb2009 Mar2009 | | | | | | | | | Apr2009 May2009 Jun2009 | | | | | | | | | Jul2009 Aug2009 Sep2009 | | | | | | | | | Oct2009 Nov2009 Dec2009 | | | | | *scratch* | *Calendar* | +-------------------------+-------------------------+ or a long stripe for as much months will fit to the window's width: +---------------------------------------------------+ | | | | | | | | | | | | | | | *scratch* | +---------------------------------------------------+ | May2009 Jun2009 Jul2009 Aug2009 Sep2009 Oct2009 | | | | *Calendar* | +---------------------------------------------------+ I guess the latter would be easier to implement? -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 06 Oct 2009 22:50:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125486893927809 (code B ref 1806); Tue, 06 Oct 2009 22:50:09 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 6 Oct 2009 22:42:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.starman.ee (smtp-out1.starman.ee [85.253.0.3]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n96MgHfb027798 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 15:42:18 -0700 X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Received: from mail.starman.ee (62.65.209.67.cable.starman.ee [62.65.209.67]) by mx1.starman.ee (Postfix) with ESMTP id BEE863F40A1; Wed, 7 Oct 2009 01:42:08 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: Stephen Berman , 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <496DF4B9.3080805@gmx.at> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <87ocol1no6.fsf@escher.local.home> Date: Wed, 07 Oct 2009 01:38:35 +0300 In-Reply-To: (Glenn Morris's message of "Mon, 05 Oct 2009 22:53:02 -0400") Message-ID: <87skdw9mhg.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> What's more, I have things configured so that calling Calendar also >> pops up the fancy diary display, and starting with a single >> (screen-) wide window, the result is similar to the above, namely: >> >> +-------------------------+ +------------+------------+ >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | | ===> | | | >> | | | | | >> | | | | *Messages* | >> | | | +------------+ >> | | | | | >> | *scratch* | | Diary | *Calendar* | >> +-------------------------+ +------------+------------+ > > As I wrote: > > The only remaining calendar issue I can see is that one might > prefer the diary to always appear directly above (or below) the > calendar, rather than to one side. This could be achieved by the > use of windmove. I might install something along those lines, or I > might not bother. I think the most expected way would be to display the calendar window below the current buffer, and to display the diary above the calendar (effectively what `d' does when invoked from the calendar) that replaces the original buffer (*scratch* in this case) with the diary buffer: +-------------------------+ +-------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | *Diary* | | | +-------------------------+ | | | | | *scratch* | | *Calendar* | +-------------------------+ +-------------------------+ -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 07 Oct 2009 03:05:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12548843115610 (code B ref 1806); Wed, 07 Oct 2009 03:05:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Oct 2009 02:58:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n972wToB005597 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 19:58:31 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MvMjU-0007Ke-Bc; Tue, 06 Oct 2009 22:58:28 -0400 From: Glenn Morris To: Stefan Monnier Cc: 1806@debbugs.gnu.org, Juri Linkov References: <87r63gzcap.fsf@jurta.org> <496E5F58.7030304@gmx.at> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> X-Spook: AUTODIN Islam Abduganievich Karimov TELINT csystems Mena X-Ran: XpSA`(KrWUxX6,+z=qT\9A)Z,`Q!qf%`O3d9Tan=M!7d-'/S9bU{Ugz?#F@DW^2FvI$X%| X-Hue: cyan X-Attribution: GM Date: Tue, 06 Oct 2009 22:58:28 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Stefan Monnier wrote: > It may be suboptimal, What is the optimal behaviour in your opinion? > but at least it doesn't end up with a weird window arrangement > displaying some randomly chosen old buffer. The buffer is no longer randomly chosen. But now I see that Juri objects to the result of that, sigh. I don't agree that the window arrangement is "weird". I suppose if the whole world continues to disagree with me, I will add `calendar-split-width-threshold', default nil. This whole exercise seems to have been a waste of time. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 07 Oct 2009 03:05:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12548843315632 (code B ref 1806); Wed, 07 Oct 2009 03:05:11 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Oct 2009 02:58:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n972wnKp005625 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 19:58:50 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MvMjo-0007do-OY; Tue, 06 Oct 2009 22:58:48 -0400 From: Glenn Morris To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics References: <87r63gzcap.fsf@jurta.org> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> <87r5tg9mhb.fsf@mail.jurta.org> X-Spook: IDEA Taiwan Reno CIA plutonium Semtex beanpole Iran X-Ran: Kp/7h3)Nxqlu>x)k?Jc)1-Nl>Ibf3Y5o#!z4DE{,xd^7LN0ZYIM>;3 X-Hue: blue X-Attribution: GM Date: Tue, 06 Oct 2009 22:58:48 -0400 Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Juri Linkov wrote: > Please don't duplicate buffers without users' consent. So I can't win. They won't accept Messages (or whatever), you won't accept another Scratch (or whatever). > I guess the latter would be easier to implement? No. Please let's not conflate these two separate issues. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 07 Oct 2009 06:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12548948983222 (code B ref 1806); Wed, 07 Oct 2009 06:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 7 Oct 2009 05:54:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n975suau003209 for <1806@emacsbugs.donarmstrong.com>; Tue, 6 Oct 2009 22:54:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAFjKy0pMCqug/2dsb2JhbACBUdMShCoEhzQ X-IronPort-AV: E=Sophos;i="4.44,517,1249272000"; d="scan'208";a="47220040" Received: from 76-10-171-160.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.160]) by ironport2-out.pppoe.ca with ESMTP; 07 Oct 2009 01:54:51 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 311C7B4190; Wed, 7 Oct 2009 01:54:51 -0400 (EDT) From: Stefan Monnier To: Glenn Morris Cc: 1806@debbugs.gnu.org, Juri Linkov Message-ID: References: <87r63gzcap.fsf@jurta.org> <496F11C0.4080700@gmx.at> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> Date: Wed, 07 Oct 2009 01:54:51 -0400 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 22:58:28 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> It may be suboptimal, > What is the optimal behaviour in your opinion? The optimal behavior depends on the user's intention, here. Calendar can't know it. So it should just strive to make it easy for the user to get what she wants. > This whole exercise seems to have been a waste of time. Yes, I'm sorry about it, but clearly the new "automatic double split" is not a good idea: sometimes it may correspond to what the user wanted, but I expect it'll be rare, and as mentioned, it's a lot easy for those users to hit C-x 3 before invoking calendar, than for the rest of them to undo the damage. KISS. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 12 Oct 2009 20:45:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12553798229969 (code B ref 1806); Mon, 12 Oct 2009 20:45:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 12 Oct 2009 20:37:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9CKb0mN009966 for <1806@emacsbugs.donarmstrong.com>; Mon, 12 Oct 2009 13:37:01 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.68.196.cable.starman.ee [82.131.68.196]) by mx2.starman.ee (Postfix) with ESMTP id 7D9263F4112; Mon, 12 Oct 2009 23:36:53 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.org> <87vditmrxs.fsf@mail.jurta.org> <78zl8544jh.fsf@fencepost.gnu.org> <4ACB0646.5030102@gmx.at> <87r5tg9mhb.fsf@mail.jurta.org> Date: Mon, 12 Oct 2009 23:32:45 +0300 In-Reply-To: (Glenn Morris's message of "Tue, 06 Oct 2009 22:58:48 -0400") Message-ID: <87tyy4qu08.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I noticed another case with weird behaviour. Please confirm is this intentional or not. When initially a frame is split horizontally in two side-by-side windows then after `M-x calendar' the calendar appears not under the current window, but under another window in the opposite pane, duplicating the buffer above it with the initially current buffer (IOW, replacing *Messages* with *scratch* in the following case): +------------+------------+ +------------+------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | | current | | | | *scratch* | | buffer | | | +------------+ | | | | | | | *scratch* | *Messages* | | *scratch* | *Calendar* | +------------+------------+ +------------+------------+ -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 12 Oct 2009 23:05:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125538822530885 (code B ref 1806); Mon, 12 Oct 2009 23:05:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 12 Oct 2009 22:57:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9CMv31G030882 for <1806@emacsbugs.donarmstrong.com>; Mon, 12 Oct 2009 15:57:04 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MxTp8-0006rh-Fe; Mon, 12 Oct 2009 18:57:02 -0400 From: Glenn Morris To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics References: <87r63gzcap.fsf@jurta.org> <87ocy8fajt.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> X-Spook: TWA Delta Force AVIP InfoSec military Cocaine X-Ran: D/2oyt,T\#z4CDCp[$0tb<$-ZR2_!hMT*F_=O2I3N X-Hue: red X-Attribution: GM Date: Mon, 12 Oct 2009 18:57:02 -0400 In-Reply-To: <87tyy4qu08.fsf@mail.jurta.org> (Juri Linkov's message of "Mon, 12 Oct 2009 23:32:45 +0300") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Juri Linkov wrote: > I noticed another case with weird behaviour. Please confirm is this > intentional or not. Well, not so much intentional, as just, this is what pop-to-buffer does. But, this is no longer the default behaviour - please try the current CVS. From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 13 Oct 2009 23:10:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.1255474843686 (code B ref 1806); Tue, 13 Oct 2009 23:10:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 13 Oct 2009 23:00:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,URIBL_CNKR autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9DN0fII000676 for <1806@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 16:00:42 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.28.50.cable.starman.ee [82.131.28.50]) by mx2.starman.ee (Postfix) with ESMTP id 15A7D3F4113; Wed, 14 Oct 2009 02:00:32 +0300 (EEST) From: Juri Linkov To: Glenn Morris Cc: 1806@debbugs.gnu.org, martin rudalics Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> Date: Wed, 14 Oct 2009 01:37:45 +0300 In-Reply-To: (Glenn Morris's message of "Mon, 12 Oct 2009 18:57:02 -0400") Message-ID: <871vl6x5un.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I noticed another case with weird behaviour. Please confirm is this >> intentional or not. > > Well, not so much intentional, as just, this is what pop-to-buffer > does. But, this is no longer the default behaviour - please try the > current CVS. Hmm, tried the current CVS and see no improvement. I mean I still see this default behaviour: +------------+------------+ +------------+------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | | current | | | | *scratch* | | buffer | | | +------------+ | | | | | | | *scratch* | *Messages* | | *scratch* | *Calendar* | +------------+------------+ +------------+------------+ I expected it to be rather: +------------+------------+ +------------+------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ===> | | | | | | | | | | current | | | *scratch* | | | buffer | | +------------+ | | | | | | | | *scratch* | *Messages* | | *Calendar* | *Messages* | +------------+------------+ +------------+------------+ -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 14 Oct 2009 20:50:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125555313832353 (code B ref 1806); Wed, 14 Oct 2009 20:50:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 14 Oct 2009 20:45:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EKja9h032345 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 13:45:37 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.99.144.cable.starman.ee [82.131.99.144]) by mx2.starman.ee (Postfix) with ESMTP id 86E683F40A3; Wed, 14 Oct 2009 23:45:30 +0300 (EEST) From: Juri Linkov To: 1806@debbugs.gnu.org Cc: Glenn Morris Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> Date: Wed, 14 Oct 2009 23:35:17 +0300 In-Reply-To: <871vl6x5un.fsf@mail.jurta.org> (Juri Linkov's message of "Wed, 14 Oct 2009 01:37:45 +0300") Message-ID: <873a5lzqhi.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> I noticed another case with weird behaviour. Please confirm is this >>> intentional or not. >> >> Well, not so much intentional, as just, this is what pop-to-buffer >> does. But, this is no longer the default behaviour - please try the >> current CVS. > > Hmm, tried the current CVS and see no improvement. I mean I still see > this default behaviour: I think the problem is the lack of the necessary primitive in window.el. Should it exist, any mode could use it with a simple function call that creates a new window below the current one even in a wide-frame configuration. I remember Martin proposed a patch during the code freeze, but currently can't find it. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 15 Oct 2009 05:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125558518021126 (code B ref 1806); Thu, 15 Oct 2009 05:45:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Oct 2009 05:39:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9F5dbi0021121 for <1806@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 22:39:39 -0700 Received: (qmail invoked by alias); 15 Oct 2009 05:39:31 -0000 Received: from 62-47-41-122.adsl.highway.telekom.at (EHLO [62.47.41.122]) [62.47.41.122] by mail.gmx.net (mp036) with SMTP; 15 Oct 2009 07:39:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/xsgA3znzxZq7pDihMK/UNqNLgpBjLGQIImoKL+Y BaZmMKKgSdlJSS Message-ID: <4AD6B592.6090700@gmx.at> Date: Thu, 15 Oct 2009 07:39:30 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <4975F4D5.5030000@gmx.at> <87y6tk1j47.fsf@mail.jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> In-Reply-To: <873a5lzqhi.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 > I think the problem is the lack of the necessary primitive in window.el. > Should it exist, any mode could use it with a simple function call > that creates a new window below the current one even in a wide-frame > configuration. I remember Martin proposed a patch during the code freeze, > but currently can't find it. I'm currently rewriting the window code so this would be a good moment to incorporate such wishlist items here. Though for the present case I'm not quite sure whether `pop-to-buffer' is the primitive you want: If you want the new window definitely appear below the selected one, then why not use `split-window' in the first place? `pop-to-buffer' should be allowed to use heuristics based on user preferences. Applications should not deliberatly override them. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Thu, 15 Oct 2009 22:40:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125564593431980 (code B ref 1806); Thu, 15 Oct 2009 22:40:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 15 Oct 2009 22:32:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9FMWC62031977 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Oct 2009 15:32:13 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.55.26.cable.starman.ee [82.131.55.26]) by mx2.starman.ee (Postfix) with ESMTP id 244D73F409D; Fri, 16 Oct 2009 01:31:56 +0300 (EEST) From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> Date: Fri, 16 Oct 2009 01:29:17 +0300 In-Reply-To: <4AD6B592.6090700@gmx.at> (martin rudalics's message of "Thu, 15 Oct 2009 07:39:30 +0200") Message-ID: <87aazswbp2.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I think the problem is the lack of the necessary primitive in window.el. >> Should it exist, any mode could use it with a simple function call >> that creates a new window below the current one even in a wide-frame >> configuration. I remember Martin proposed a patch during the code freeze, >> but currently can't find it. > > I'm currently rewriting the window code so this would be a good moment > to incorporate such wishlist items here. Though for the present case > I'm not quite sure whether `pop-to-buffer' is the primitive you want: If > you want the new window definitely appear below the selected one, then > why not use `split-window' in the first place? `pop-to-buffer' should > be allowed to use heuristics based on user preferences. Applications > should not deliberatly override them. I think some applications (where such exceptions make sense) by default should ignore split-width-threshold and let `pop-to-buffer' to split vertically. And window.el should provide a simple user option to define these exceptions that will specify how to split windows based on the buffer names similar to `same-window-buffer-names'. For instance, (defcustom split-window-buffer-names '(("*Calendar*" . vertically) (" *Marked Files*" . vertically)) -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 00:40:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125565303719666 (code B ref 1806); Fri, 16 Oct 2009 00:40:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 00:30:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9G0UZW2019658 for <1806@emacsbugs.donarmstrong.com>; Thu, 15 Oct 2009 17:30:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAN5b10pFpY7q/2dsb2JhbACBUtdChDAEh3k X-IronPort-AV: E=Sophos;i="4.44,569,1249272000"; d="scan'208";a="47655880" Received: from 69-165-142-234.dsl.teksavvy.com (HELO pastel.home) ([69.165.142.234]) by ironport2-out.pppoe.ca with ESMTP; 15 Oct 2009 20:30:29 -0400 Received: by pastel.home (Postfix, from userid 20848) id 052F47F87; Thu, 15 Oct 2009 20:30:28 -0400 (EDT) From: Stefan Monnier To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> Date: Thu, 15 Oct 2009 20:30:28 -0400 In-Reply-To: <87aazswbp2.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 16 Oct 2009 01:29:17 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > I think some applications (where such exceptions make sense) by default > should ignore split-width-threshold and let `pop-to-buffer' to split > vertically. And window.el should provide a simple user option to define > these exceptions that will specify how to split windows based on the > buffer names similar to `same-window-buffer-names'. For instance, > (defcustom split-window-buffer-names > '(("*Calendar*" . vertically) > (" *Marked Files*" . vertically)) Please don't use a new variable, but just extend special-display-buffer-names. It currently already accepts some special parameters such as same-frame, so it could also handle new parameters like `split-orientation' with values `side-by-side' or `top-down'. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 07:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125567671123428 (code B ref 1806); Fri, 16 Oct 2009 07:15:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 07:05:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9G758pG022552 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 00:05:10 -0700 Received: (qmail invoked by alias); 16 Oct 2009 07:05:02 -0000 Received: from 62-47-35-49.adsl.highway.telekom.at (EHLO [62.47.35.49]) [62.47.35.49] by mail.gmx.net (mp005) with SMTP; 16 Oct 2009 09:05:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19fL69XFVxfg1vkkp4HdJvmbBAX9jKLNuSDJIZIXh h/GGM1Ir4OAdd8 Message-ID: <4AD81B1C.6040203@gmx.at> Date: Fri, 16 Oct 2009 09:05:00 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <49F7FE14.8010107@gmx.at> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> In-Reply-To: <87aazswbp2.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 > I think some applications (where such exceptions make sense) by default > should ignore split-width-threshold and let `pop-to-buffer' to split > vertically. And window.el should provide a simple user option to define > these exceptions that will specify how to split windows based on the > buffer names similar to `same-window-buffer-names'. For instance, > > (defcustom split-window-buffer-names > '(("*Calendar*" . vertically) > (" *Marked Files*" . vertically)) Is there a good reason why these applications should endure the present heuristics of `pop-to-buffer' in the first place? Shouldn't *Marked Files* appear beneath the window where the marking took place? That latter window might not be the largest one and is almost certainly not the LRU one, so the *Marked Files* window might not show up in a very suitable place anyway. I suppose the *Marked Files* window should be obtained by first trying to deterministically split the window where the marking took place and only when splitting fails have `pop-to-buffer' find a suitable window. So what I really need to know is how you (1) expect this to work ideally, and (2) how to proceed when (1) fails. As for the *Calendar* window I thought that Glenn wanted to do some side-by-side splitting first because of the wasted space in a frame-wide *Calendar* window. So your proposal wouldn't help in this case. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 07:15:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125567672523764 (code B ref 1806); Fri, 16 Oct 2009 07:15:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 07:05:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9G75Ni0023609 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 00:05:24 -0700 Received: (qmail invoked by alias); 16 Oct 2009 07:05:17 -0000 Received: from 62-47-35-49.adsl.highway.telekom.at (EHLO [62.47.35.49]) [62.47.35.49] by mail.gmx.net (mp021) with SMTP; 16 Oct 2009 09:05:17 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+9Sp0BsGq9Cl5WDaLUv2yvqcfT7r2Lo81LAyu/R/ Ct5aojpTWryc8p Message-ID: <4AD81B2B.8040805@gmx.at> Date: Fri, 16 Oct 2009 09:05:15 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 > Please don't use a new variable, but just extend > special-display-buffer-names. It currently already accepts some special > parameters such as same-frame, so it could also handle new parameters > like `split-orientation' with values `side-by-side' or `top-down'. `special-display-popup-frame' is a misnomer (and sits in the wrong file) if we continue to overload it with such window specific enhancements. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Juri Linkov , 1806@debbugs.gnu.org Resent-From: Juri Linkov Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 11:00:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569038030586 (code B ref 1806); Fri, 16 Oct 2009 11:00:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 10:53:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx2.starman.ee (smtp-out2.starman.ee [85.253.0.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GAqwr7030579 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 03:52:59 -0700 X-Virus-Scanned: by Amavisd-New at mx2.starman.ee Received: from mail.starman.ee (82.131.99.176.cable.starman.ee [82.131.99.176]) by mx2.starman.ee (Postfix) with ESMTP id AB69A3F4109; Fri, 16 Oct 2009 13:52:51 +0300 (EEST) From: Juri Linkov To: martin rudalics Cc: 1806@debbugs.gnu.org Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> <4AD81B1C.6040203@gmx.at> Date: Fri, 16 Oct 2009 12:38:43 +0300 In-Reply-To: <4AD81B1C.6040203@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 09:05:00 +0200") Message-ID: <87bpk74nsk.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I think some applications (where such exceptions make sense) by default >> should ignore split-width-threshold and let `pop-to-buffer' to split >> vertically. And window.el should provide a simple user option to define >> these exceptions that will specify how to split windows based on the >> buffer names similar to `same-window-buffer-names'. For instance, >> >> (defcustom split-window-buffer-names >> '(("*Calendar*" . vertically) >> (" *Marked Files*" . vertically)) > > Is there a good reason why these applications should endure the present > heuristics of `pop-to-buffer' in the first place? Shouldn't *Marked > Files* appear beneath the window where the marking took place? That > latter window might not be the largest one and is almost certainly not > the LRU one, so the *Marked Files* window might not show up in a very > suitable place anyway. I suppose the *Marked Files* window should be > obtained by first trying to deterministically split the window where the > marking took place and only when splitting fails have `pop-to-buffer' > find a suitable window. That's what I actually meant and what `dired-pop-to-buffer' already does. > So what I really need to know is how you (1) expect this to work > ideally, and (2) how to proceed when (1) fails. I think the current behavior of `dired-pop-to-buffer' is ideal in this regard. We just have to generalize it and move its logic to window.el to allow other applications to use the same logic. > As for the *Calendar* window I thought that Glenn wanted to do some > side-by-side splitting first because of the wasted space in a frame-wide > *Calendar* window. So your proposal wouldn't help in this case. We should not decide on behalf of the user what window space is wasted and fill it with some arbitrary buffers. -- Juri Linkov http://www.jurta.org/emacs/ From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 12:10:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569470715157 (code B ref 1806); Fri, 16 Oct 2009 12:10:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 12:05:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9GC55IM014579 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 05:05:06 -0700 Received: (qmail invoked by alias); 16 Oct 2009 12:04:58 -0000 Received: from 62-47-56-246.adsl.highway.telekom.at (EHLO [62.47.56.246]) [62.47.56.246] by mail.gmx.net (mp005) with SMTP; 16 Oct 2009 14:04:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19MJrlc0d9MClBZVmO+8vgQjLRAhxVK3pFCoSLInZ 4iJqexC3Se1PoX Message-ID: <4AD86168.8010307@gmx.at> Date: Fri, 16 Oct 2009 14:04:56 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Juri Linkov CC: 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <49FFE515.4020608@gmx.at> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> <4AD81B1C.6040203@gmx.at> <87bpk74nsk.fsf@mail.jurta.org> In-Reply-To: <87bpk74nsk.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 >>> I think some applications (where such exceptions make sense) by default >>> should ignore split-width-threshold and let `pop-to-buffer' to split >>> vertically. And window.el should provide a simple user option to define >>> these exceptions that will specify how to split windows based on the >>> buffer names similar to `same-window-buffer-names'. For instance, >>> >>> (defcustom split-window-buffer-names >>> '(("*Calendar*" . vertically) >>> (" *Marked Files*" . vertically)) >> Is there a good reason why these applications should endure the present >> heuristics of `pop-to-buffer' in the first place? Shouldn't *Marked >> Files* appear beneath the window where the marking took place? That >> latter window might not be the largest one and is almost certainly not >> the LRU one, so the *Marked Files* window might not show up in a very >> suitable place anyway. I suppose the *Marked Files* window should be >> obtained by first trying to deterministically split the window where the >> marking took place and only when splitting fails have `pop-to-buffer' >> find a suitable window. > > That's what I actually meant and what `dired-pop-to-buffer' already does. `dired-pop-to-buffer' explicitly specifies that it wants to split the selected window. Your defcustom does not specifiy _which_ window to split. >> So what I really need to know is how you (1) expect this to work >> ideally, and (2) how to proceed when (1) fails. > > I think the current behavior of `dired-pop-to-buffer' is ideal in this > regard. We just have to generalize it and move its logic to window.el > to allow other applications to use the same logic. For that purpose we would have to specify (1) which window should be split preferably and (2) how to split that window. >> As for the *Calendar* window I thought that Glenn wanted to do some >> side-by-side splitting first because of the wasted space in a frame-wide >> *Calendar* window. So your proposal wouldn't help in this case. > > We should not decide on behalf of the user what window space is wasted > and fill it with some arbitrary buffers. I agree. We're in a lose-lose situation here. Popping up a separate frame would be probably better here. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 13:20:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569860627019 (code B ref 1806); Fri, 16 Oct 2009 13:20:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 13:10:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9GDA41U026874 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 06:10:06 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAP4N2EpFpY7q/2dsb2JhbACBU9dOhDAEh3w X-IronPort-AV: E=Sophos;i="4.44,573,1249272000"; d="scan'208";a="47681375" Received: from 69-165-142-234.dsl.teksavvy.com (HELO pastel.home) ([69.165.142.234]) by ironport2-out.pppoe.ca with ESMTP; 16 Oct 2009 09:09:58 -0400 Received: by pastel.home (Postfix, from userid 20848) id 8A01F7F87; Fri, 16 Oct 2009 09:09:58 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> Date: Fri, 16 Oct 2009 09:09:58 -0400 In-Reply-To: <4AD81B2B.8040805@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 09:05:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> Please don't use a new variable, but just extend >> special-display-buffer-names. It currently already accepts some special >> parameters such as same-frame, so it could also handle new parameters >> like `split-orientation' with values `side-by-side' or `top-down'. > `special-display-popup-frame' is a misnomer (and sits in the wrong file) > if we continue to overload it with such window specific enhancements. Hmm... I did write special-display-buffer-names rather than special-display-popup-frame, didn't I? Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 13:20:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569894928293 (code B ref 1806); Fri, 16 Oct 2009 13:20:08 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 13:15:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GDFlfk028274 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 06:15:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEACoP2EpFpY7q/2dsb2JhbACBU9dBhDAEh3w X-IronPort-AV: E=Sophos;i="4.44,573,1249272000"; d="scan'208";a="47681753" Received: from 69-165-142-234.dsl.teksavvy.com (HELO pastel.home) ([69.165.142.234]) by ironport2-out.pppoe.ca with ESMTP; 16 Oct 2009 09:15:41 -0400 Received: by pastel.home (Postfix, from userid 20848) id BC6B77F87; Fri, 16 Oct 2009 09:15:41 -0400 (EDT) From: Stefan Monnier To: Juri Linkov Cc: 1806@debbugs.gnu.org, martin rudalics Message-ID: References: <87r63gzcap.fsf@jurta.org> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> <4AD81B1C.6040203@gmx.at> <87bpk74nsk.fsf@mail.jurta.org> Date: Fri, 16 Oct 2009 09:15:41 -0400 In-Reply-To: <87bpk74nsk.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 16 Oct 2009 12:38:43 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> So what I really need to know is how you (1) expect this to work >> ideally, and (2) how to proceed when (1) fails. > I think the current behavior of `dired-pop-to-buffer' is ideal in this > regard. We just have to generalize it and move its logic to window.el > to allow other applications to use the same logic. Agreed. As discussed in some earlier thread, I think the `not-this-window' argument of diaplay-buffer (aka `other-window' for pop-to-buffer) should be extended to allow a description of where the buffer should preferentially go (i.e. the application's preference), where one such preference could be `nearby' or `near-minibuffer' which would basically mean to follow the rules of dired-pop-to-buffer. These preferences would be subject to overruling via special-display-regexps. >> As for the *Calendar* window I thought that Glenn wanted to do some >> side-by-side splitting first because of the wasted space in a frame-wide >> *Calendar* window. So your proposal wouldn't help in this case. > We should not decide on behalf of the user what window space is wasted > and fill it with some arbitrary buffers. Agreed. If side-by-side splitting is desirable, it is the user's responsibility to do C-x 3 before invoking calendar. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 13:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569953730032 (code B ref 1806); Fri, 16 Oct 2009 13:30:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 13:25:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9GDPZUQ030023 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 06:25:36 -0700 Received: (qmail invoked by alias); 16 Oct 2009 13:25:28 -0000 Received: from 62-47-56-246.adsl.highway.telekom.at (EHLO [62.47.56.246]) [62.47.56.246] by mail.gmx.net (mp043) with SMTP; 16 Oct 2009 15:25:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+bnngUxz6bTvgn8spmlqSB+4kZkbef0CYYpAQ3zg sG/MS0YpvoRdgI Message-ID: <4AD87446.4090303@gmx.at> Date: Fri, 16 Oct 2009 15:25:26 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <87vdnzpks0.fsf@mail.jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 >> `special-display-popup-frame' is a misnomer (and sits in the wrong file) >> if we continue to overload it with such window specific enhancements. > > Hmm... I did write special-display-buffer-names rather than > special-display-popup-frame, didn't I? Right. But a match for `special-display-buffer-names' triggers the call of `special-display-function' whose default value is `special-display-popup-frame'. And the latter has to handle all those nasty things like 'same-window and 'same-frame, popping up a new frame only as last resort. That function has gone a long way ... martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 15:45:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125570746520535 (code B ref 1806); Fri, 16 Oct 2009 15:45:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 15:37:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GFbhiw020532 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 08:37:45 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAPsv2EpFpY7q/2dsb2JhbACBUdd3hDAEh3w X-IronPort-AV: E=Sophos;i="4.44,574,1249272000"; d="scan'208";a="47691610" Received: from 69-165-142-234.dsl.teksavvy.com (HELO pastel.home) ([69.165.142.234]) by ironport2-out.pppoe.ca with ESMTP; 16 Oct 2009 11:37:38 -0400 Received: by pastel.home (Postfix, from userid 20848) id B003A7F87; Fri, 16 Oct 2009 11:37:37 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <27ljouutzk.fsf@fencepost.gnu.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> Date: Fri, 16 Oct 2009 11:37:37 -0400 In-Reply-To: <4AD87446.4090303@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 15:25:26 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> `special-display-popup-frame' is a misnomer (and sits in the wrong file) >>> if we continue to overload it with such window specific enhancements. >> Hmm... I did write special-display-buffer-names rather than >> special-display-popup-frame, didn't I? > Right. But a match for `special-display-buffer-names' triggers the call > of `special-display-function' whose default value is > `special-display-popup-frame'. And the latter has to handle all those > nasty things like 'same-window and 'same-frame, popping up a new frame > only as last resort. That function has gone a long way ... Oh, I see what you mean now. Yes, it deserves a rename. But that's trivial to do, isn't it? Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Glenn Morris , 1806@debbugs.gnu.org Resent-From: Glenn Morris Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 16:20:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125570945726778 (code B ref 1806); Fri, 16 Oct 2009 16:20:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 16:10:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-6.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GGAtjT026775 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 09:10:56 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MypOI-0007VI-7Y; Fri, 16 Oct 2009 12:10:54 -0400 From: Glenn Morris To: martin rudalics Cc: 1806@debbugs.gnu.org, Juri Linkov References: <87r63gzcap.fsf@jurta.org> <4A11184F.4030606@gmx.at> <27ljouutzk.fsf@fencepost.gnu.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> <4AD81B1C.6040203@gmx.at> <87bpk74nsk.fsf@mail.jurta.org> <4AD86168.8010307@gmx.at> X-Spook: South Africa Montenegro csim Marxist counter intelligence X-Ran: ]FoaUbyfJiU8G8vMbG0|IcQMnhrDRrO}4fO*D>8q%M[1MXD0|{ZGrtR4BMR-b|=_%g`^t^ X-Hue: blue X-Attribution: GM Date: Fri, 16 Oct 2009 12:10:54 -0400 In-Reply-To: <4AD86168.8010307@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 14:04:56 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii martin rudalics wrote: >>> As for the *Calendar* window I thought that Glenn wanted to do some >>> side-by-side splitting first because of the wasted space in a frame-wide >>> *Calendar* window. So your proposal wouldn't help in this case. >> >> We should not decide on behalf of the user what window space is wasted >> and fill it with some arbitrary buffers. > > I agree. We're in a lose-lose situation here. Popping up a separate > frame would be probably better here. Once again: this is no longer the default behaviour. I think this bug is now far too long and complex to understand. I suggest starting a new one with a summary of the outstanding issues. (not volunteering) From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 16:40:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125571094631111 (code B ref 1806); Fri, 16 Oct 2009 16:40:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 16:35:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9GGZheq031099 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 09:35:45 -0700 Received: (qmail invoked by alias); 16 Oct 2009 16:35:37 -0000 Received: from 62-47-56-246.adsl.highway.telekom.at (EHLO [62.47.56.246]) [62.47.56.246] by mail.gmx.net (mp060) with SMTP; 16 Oct 2009 18:35:37 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19CKksBTD1CsiYhextMrvwVKg1N0g5PsyhQ9ZZb16 is8Dhd+XeU9mmU Message-ID: <4AD8A0D7.9060409@gmx.at> Date: Fri, 16 Oct 2009 18:35:35 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <27ljouutzk.fsf@fencepost.gnu.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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 > Oh, I see what you mean now. Yes, it deserves a rename. But that's > trivial to do, isn't it? Renaming the function is trivial. The problem is finding meaningful additional "frame-parameters" like 'same-window and 'same-frame and how to make them interact with `pop-up-windows' and `pop-up-frames'. I'm afraid there are few people with non-nil `special-display-buffer-names' already. Making this more complicated won't help anyone. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 20:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12557256816322 (code B ref 1806); Fri, 16 Oct 2009 20:50:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 20:41:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.2 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GKfJsR006318 for <1806@emacsbugs.donarmstrong.com>; Fri, 16 Oct 2009 13:41:20 -0700 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n9GKfHk0012130; Fri, 16 Oct 2009 16:41:18 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id CBE9B3A3C3; Fri, 16 Oct 2009 16:41:17 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: 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> Date: Fri, 16 Oct 2009 16:41:17 -0400 In-Reply-To: <4AD8A0D7.9060409@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 18:35:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3386=0 >> Oh, I see what you mean now. Yes, it deserves a rename. But that's >> trivial to do, isn't it? > 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. 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. > and how to make them interact with `pop-up-windows' and > `pop-up-frames'. I don't see much difficulty here. > 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. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 17 Oct 2009 09:10:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125577019718621 (code B ref 1806); Sat, 17 Oct 2009 09:10:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 17 Oct 2009 09:03:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 Received: (qmail invoked by alias); 17 Oct 2009 09:03:08 -0000 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 Message-ID: <4AD9884B.6000609@gmx.at> Date: Sat, 17 Oct 2009 11:03:07 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 >> 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 From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 01:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125583000917230 (code B ref 1806); Sun, 18 Oct 2009 01:50:03 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 01:40:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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" 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 Received: by pastel.home (Postfix, from userid 20848) id C4D1F7FD5; Sat, 17 Oct 2009 21:40:01 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org 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> Date: Sat, 17 Oct 2009 21:40:01 -0400 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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 From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 10:30:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12558614949926 (code B ref 1806); Sun, 18 Oct 2009 10:30:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 10:24:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 Received: (qmail invoked by alias); 18 Oct 2009 10:24:44 -0000 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 Message-ID: <4ADAECEB.2080101@gmx.at> Date: Sun, 18 Oct 2009 12:24:43 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 > [ "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 From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 14:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125587712622446 (code B ref 1806); Sun, 18 Oct 2009 14:50:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 14:45:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9IEjO0d022440 for <1806@emacsbugs.donarmstrong.com>; Sun, 18 Oct 2009 07:45:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAE3H2krO+IKD/2dsb2JhbACBUtU4hDEEiAU X-IronPort-AV: E=Sophos;i="4.44,581,1249272000"; d="scan'208";a="47760722" Received: from 206-248-130-131.dsl.teksavvy.com (HELO pastel.home) ([206.248.130.131]) by ironport2-out.pppoe.ca with ESMTP; 18 Oct 2009 10:45:19 -0400 Received: by pastel.home (Postfix, from userid 20848) id 0E0F27FD5; Sun, 18 Oct 2009 10:45:19 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org 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> <4ADAECEB.2080101@gmx.at> Date: Sun, 18 Oct 2009 10:45:19 -0400 In-Reply-To: <4ADAECEB.2080101@gmx.at> (martin rudalics's message of "Sun, 18 Oct 2009 12:24:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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. It would not override settings in special-display-buffer-names. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 15:55:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12558804802112 (code B ref 1806); Sun, 18 Oct 2009 15:55:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 18 Oct 2009 15:41:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9IFfHQY002084 for <1806@emacsbugs.donarmstrong.com>; Sun, 18 Oct 2009 08:41:18 -0700 Received: (qmail invoked by alias); 18 Oct 2009 15:34:31 -0000 Received: from 62-47-61-72.adsl.highway.telekom.at (EHLO [62.47.61.72]) [62.47.61.72] by mail.gmx.net (mp050) with SMTP; 18 Oct 2009 17:34:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX187mv1wUiQ7Mi1mWnd6l03R8/fe41tHNs4nb3kbgr UXxh4bPltCdLlC Message-ID: <4ADB3586.1050708@gmx.at> Date: Sun, 18 Oct 2009 17:34:30 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org 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> <4ADAECEB.2080101@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 >>> 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. > > It would not override settings in special-display-buffer-names. I just wanted to make sure that with "Things like `same-window'" you do not intend a (same-window . t) entry in `special-display-buffer-names'. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 02:15:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.12559180974816 (code B ref 1806); Mon, 19 Oct 2009 02:15:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 Oct 2009 02:08:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9J28FsG004813 for <1806@emacsbugs.donarmstrong.com>; Sun, 18 Oct 2009 19:08:17 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAKNm20pLd/m0/2dsb2JhbACBUtdchDEEiAU X-IronPort-AV: E=Sophos;i="4.44,582,1249272000"; d="scan'208";a="47776622" Received: from 75-119-249-180.dsl.teksavvy.com (HELO ceviche.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 18 Oct 2009 22:08:10 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 164F3B408B; Sun, 18 Oct 2009 22:08:10 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> Date: Sun, 18 Oct 2009 22:08:09 -0400 In-Reply-To: <4ADB3586.1050708@gmx.at> (martin rudalics's message of "Sun, 18 Oct 2009 17:34:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> It would not override settings in special-display-buffer-names. > I just wanted to make sure that with "Things like `same-window'" you do > not intend a (same-window . t) entry in `special-display-buffer-names'. The way I see it, the `other-window' argument to pop-to-buffer should be able to provide such settings as well. I.e. they could be provided both by the user in s-d-b-n and by the code in other-window. And of course, application-provided settings would only take precedence over global settings and not over user cutomizations. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 07:45:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125593778920532 (code B ref 1806); Mon, 19 Oct 2009 07:45:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 Oct 2009 07:36:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9J7aRpl020529 for <1806@emacsbugs.donarmstrong.com>; Mon, 19 Oct 2009 00:36:29 -0700 Received: (qmail invoked by alias); 19 Oct 2009 07:36:22 -0000 Received: from 62-47-42-63.adsl.highway.telekom.at (EHLO [62.47.42.63]) [62.47.42.63] by mail.gmx.net (mp033) with SMTP; 19 Oct 2009 09:36:22 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+bd4ZvzQubaxoYZoZBwnW1fbw0ETaZiZC9tng5bU SH7QYaVFYoKklx Message-ID: <4ADC16F4.8060609@gmx.at> Date: Mon, 19 Oct 2009 09:36:20 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@jurta.org> <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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 >>> It would not override settings in special-display-buffer-names. >> I just wanted to make sure that with "Things like `same-window'" you do >> not intend a (same-window . t) entry in `special-display-buffer-names'. > > The way I see it, the `other-window' argument to pop-to-buffer should be > able to provide such settings as well. I.e. they could be provided both > by the user in s-d-b-n and by the code in other-window. And of course, > application-provided settings would only take precedence over global > settings and not over user cutomizations. Currently, OTHER-WINDOW non-nil is an application-provided setting and takes precedence over user customizations. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 14:10:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125596090813661 (code B ref 1806); Mon, 19 Oct 2009 14:10:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 Oct 2009 14:01:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9JE1lND013658 for <1806@emacsbugs.donarmstrong.com>; Mon, 19 Oct 2009 07:01:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EADcO3EpLd/m0/2dsb2JhbACBUtlrhDEEiAU X-IronPort-AV: E=Sophos;i="4.44,585,1249272000"; d="scan'208";a="47805131" Received: from 75-119-249-180.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 19 Oct 2009 10:01:41 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6ED6B80E7; Mon, 19 Oct 2009 10:01:41 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> Date: Mon, 19 Oct 2009 10:01:41 -0400 In-Reply-To: <4ADC16F4.8060609@gmx.at> (martin rudalics's message of "Mon, 19 Oct 2009 09:36:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> I just wanted to make sure that with "Things like `same-window'" you do >>> not intend a (same-window . t) entry in `special-display-buffer-names'. >> The way I see it, the `other-window' argument to pop-to-buffer should be >> able to provide such settings as well. I.e. they could be provided both >> by the user in s-d-b-n and by the code in other-window. And of course, >> application-provided settings would only take precedence over global >> settings and not over user cutomizations. > Currently, OTHER-WINDOW non-nil is an application-provided setting Right, and it will stay this way. > and takes precedence over user customizations. We would want to change that, then. Note that the only customization it can override is the `same-window' one IIUC, which is pretty new, so it currently only overrides user customizations in very rare cases and I'm not sure that it's a feature rather than a bug. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 15:25:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125596537725590 (code B ref 1806); Mon, 19 Oct 2009 15:25:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 Oct 2009 15:16:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9JFGFgF025587 for <1806@emacsbugs.donarmstrong.com>; Mon, 19 Oct 2009 08:16:16 -0700 Received: (qmail invoked by alias); 19 Oct 2009 15:16:09 -0000 Received: from 62-47-34-6.adsl.highway.telekom.at (EHLO [62.47.34.6]) [62.47.34.6] by mail.gmx.net (mp059) with SMTP; 19 Oct 2009 17:16:09 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19BCeg8rHBB2UlSWTZFfJci06I7RCzmvP5TZSwUNn 7HjYziy6FpHwXp Message-ID: <4ADC82B5.5020506@gmx.at> Date: Mon, 19 Oct 2009 17:16:05 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 >> Currently, OTHER-WINDOW non-nil is an application-provided setting > > Right, and it will stay this way. > >> and takes precedence over user customizations. > > We would want to change that, then. > > Note that the only customization it can override is the `same-window' > one IIUC, which is pretty new, so it currently only overrides user > customizations in very rare cases and I'm not sure that it's a feature > rather than a bug. Should `switch-to-buffer-other-window' then be allowed to display the buffer in the same window? The Elisp manual would certainly forbid such behavior: The currently selected window is absolutely never used to do the job. If it is the only window, then it is split to make a distinct window for this purpose. If the selected window is already displaying the buffer, then it continues to do so, but another window is nonetheless found to display it in as well. And the OTHER-WINDOW argument was invented precisely to handle `switch-to-buffer-other-window' via `display-buffer', IIUC. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 18:40:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125597733123766 (code B ref 1806); Mon, 19 Oct 2009 18:40:11 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 19 Oct 2009 18:35:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9JIZSoe023762 for <1806@emacsbugs.donarmstrong.com>; Mon, 19 Oct 2009 11:35:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAKtO3EpLd/m0/2dsb2JhbACBUdlyhDEEiAU X-IronPort-AV: E=Sophos;i="4.44,586,1249272000"; d="scan'208";a="47825236" Received: from 75-119-249-180.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 19 Oct 2009 14:35:22 -0400 Received: by pastel.home (Postfix, from userid 20848) id A459280E7; Mon, 19 Oct 2009 14:35:22 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> <4ADC82B5.5020506@gmx.at> Date: Mon, 19 Oct 2009 14:35:22 -0400 In-Reply-To: <4ADC82B5.5020506@gmx.at> (martin rudalics's message of "Mon, 19 Oct 2009 17:16:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "martin" == martin rudalics writes: >>> Currently, OTHER-WINDOW non-nil is an application-provided setting >> >> Right, and it will stay this way. >> >>> and takes precedence over user customizations. >> >> We would want to change that, then. >> >> Note that the only customization it can override is the `same-window' >> one IIUC, which is pretty new, so it currently only overrides user >> customizations in very rare cases and I'm not sure that it's a feature >> rather than a bug. > Should `switch-to-buffer-other-window' then be allowed to display the > buffer in the same window? The Elisp manual would certainly forbid such > behavior: > The currently selected window is absolutely never used to do the > job. If it is the only window, then it is split to make a > distinct window for this purpose. If the selected window is > already displaying the buffer, then it continues to do so, but > another window is nonetheless found to display it in as well. > And the OTHER-WINDOW argument was invented precisely to handle > `switch-to-buffer-other-window' via `display-buffer', IIUC. I guess that depends on why switch-to-buffer-other-window uses pop-to-buffer. Note that the use of pop-to-buffer already causes the curent behavior to be different from the doc you cite: with pop-up-frames set to non-nil, if the currently selected window is the only window, it is not split: another frame is creqated instead. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 20 Oct 2009 07:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125602415511857 (code B ref 1806); Tue, 20 Oct 2009 07:45:05 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 20 Oct 2009 07:35:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9K7Zr4O011853 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Oct 2009 00:35:55 -0700 Received: (qmail invoked by alias); 20 Oct 2009 07:35:47 -0000 Received: from 62-47-52-240.adsl.highway.telekom.at (EHLO [62.47.52.240]) [62.47.52.240] by mail.gmx.net (mp049) with SMTP; 20 Oct 2009 09:35:47 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+yzg8Ujt6ynvfvEzoVHP4+mrVEvM6F+tkfqA8E0k bByI3VYr2OcYo9 Message-ID: <4ADD6851.7090001@gmx.at> Date: Tue, 20 Oct 2009 09:35:45 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> <4ADC82B5.5020506@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 > I guess that depends on why switch-to-buffer-other-window uses > pop-to-buffer. Because it was convenient that way - before 1985 just as now. > Note that the use of pop-to-buffer already causes the curent behavior to > be different from the doc you cite: with pop-up-frames set to non-nil, > if the currently selected window is the only window, it is not split: > another frame is creqated instead. Indeed. But my point remains that I'm not sure whether switching from `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer' and not using the selected window in the former (or using the selected window in the latter) case might cause indignations of users. Also so because the `switch-to...' functions are frequently used by Elisp code. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 20 Oct 2009 13:35:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125604543832100 (code B ref 1806); Tue, 20 Oct 2009 13:35:06 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 20 Oct 2009 13:30:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9KDUbWP032092 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Oct 2009 06:30:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAHNY3UpLd/m0/2dsb2JhbACBUdgQhDEEiAo X-IronPort-AV: E=Sophos;i="4.44,591,1249272000"; d="scan'208";a="47863904" Received: from 75-119-249-180.dsl.teksavvy.com (HELO ceviche.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 20 Oct 2009 09:30:31 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 74A50B408B; Tue, 20 Oct 2009 09:30:31 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> <4ADC82B5.5020506@gmx.at> <4ADD6851.7090001@gmx.at> Date: Tue, 20 Oct 2009 09:30:31 -0400 In-Reply-To: <4ADD6851.7090001@gmx.at> (martin rudalics's message of "Tue, 20 Oct 2009 09:35:45 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> I guess that depends on why switch-to-buffer-other-window uses >> pop-to-buffer. > Because it was convenient that way - before 1985 just as now. Than the right fix might be to change switch-to-buffer-other-window to not use pop-to-buffer or to use it in an even more awkward way (binding special-display-buffer-names to nil arounf the call and things like that). > Indeed. But my point remains that I'm not sure whether switching from > `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer' > and not using the selected window in the former (or using the selected > window in the latter) case might cause indignations of users. I'm not sure I understand. We're talking about changing display-buffer and pop-to-buffer, not switch-to-buffer (and hopefully not switch-to-buffer-other-window, tho it may end up being affected somewhat). > Also so because the `switch-to...' functions are frequently used by > Elisp code. It's a concern but not a very serious one: I already consider such uses as problems to be fixed. Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: martin rudalics , 1806@debbugs.gnu.org Resent-From: martin rudalics Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 20 Oct 2009 15:20:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125605167214906 (code B ref 1806); Tue, 20 Oct 2009 15:20:04 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 20 Oct 2009 15:14:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9KFEUU7014903 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Oct 2009 08:14:31 -0700 Received: (qmail invoked by alias); 20 Oct 2009 15:14:20 -0000 Received: from 62-47-34-217.adsl.highway.telekom.at (EHLO [62.47.34.217]) [62.47.34.217] by mail.gmx.net (mp011) with SMTP; 20 Oct 2009 17:14:20 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18AYDUsG7cA6JEDJ6tL1Kv4eMPoSD56YeGtIy28yK Flyu6T9M9i8hIn Message-ID: <4ADDD3CB.40102@gmx.at> Date: Tue, 20 Oct 2009 17:14:19 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: Juri Linkov , 1806@debbugs.gnu.org References: <87r63gzcap.fsf@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> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> <4ADC82B5.5020506@gmx.at> <4ADD6851.7090001@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 > Than the right fix might be to change switch-to-buffer-other-window to > not use pop-to-buffer or to use it in an even more awkward way (binding > special-display-buffer-names to nil arounf the call and things like > that). IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'. Not using `pop-to-buffer' would mean we'd have to duplicate most of the code of `display-buffer' omitting only the parts that deal with the `same-window-...' and `special-display-...' variables. So I think it would be easier to have `switch-to-buffer-other-window' pass the constant 'other-window to `display-buffer' and handle that case specially there. In principle this means that we'd have to ignore the `same-window-...' variables and make sure that `special-display-function' does not return the same window. `switch-to-buffer-other-frame' then would have to pass 'other-frame to `display-buffer' and be handled in a similar manner. >> Indeed. But my point remains that I'm not sure whether switching from >> `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer' >> and not using the selected window in the former (or using the selected >> window in the latter) case might cause indignations of users. > > I'm not sure I understand. We're talking about changing display-buffer > and pop-to-buffer, not switch-to-buffer (and hopefully not > switch-to-buffer-other-window, tho it may end up being affected > somewhat). What I meant is that when we have `display-buffer' not let the NOT-THIS-WINDOW argument override user customizations we'd change the semantics of `switch-to-buffer-other-window/-frame'. I suppose we can't end up having these display the buffer in the same window so we somehow have to make sure that the NOT-THIS-WINDOW/OTHER-WINDOW argument is handled specially for these functions (if they use `display-buffer'). >> Also so because the `switch-to...' functions are frequently used by >> Elisp code. > > It's a concern but not a very serious one: I already consider such uses > as problems to be fixed. Well, there's lots of them :-( martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#1806: dired-pop-to-buffer in wrong place Reply-To: Stefan Monnier , 1806@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 20 Oct 2009 19:55:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125606796522763 (code B ref 1806); Tue, 20 Oct 2009 19:55:07 +0000 Received: (at 1806) by emacsbugs.donarmstrong.com; 20 Oct 2009 19:46:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9KJk2uE022754 for <1806@emacsbugs.donarmstrong.com>; Tue, 20 Oct 2009 12:46:04 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAJOw3UpLd/m0/2dsb2JhbACBUdl9hDEEiAo X-IronPort-AV: E=Sophos;i="4.44,593,1249272000"; d="scan'208";a="47895763" Received: from 75-119-249-180.dsl.teksavvy.com (HELO pastel.home) ([75.119.249.180]) by ironport2-out.pppoe.ca with ESMTP; 20 Oct 2009 15:45:57 -0400 Received: by pastel.home (Postfix, from userid 20848) id 0381880E7; Tue, 20 Oct 2009 15:45:56 -0400 (EDT) From: Stefan Monnier To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Message-ID: References: <87r63gzcap.fsf@jurta.org> <4AD81B2B.8040805@gmx.at> <4AD87446.4090303@gmx.at> <4AD8A0D7.9060409@gmx.at> <4AD9884B.6000609@gmx.at> <4ADAECEB.2080101@gmx.at> <4ADB3586.1050708@gmx.at> <4ADC16F4.8060609@gmx.at> <4ADC82B5.5020506@gmx.at> <4ADD6851.7090001@gmx.at> <4ADDD3CB.40102@gmx.at> Date: Tue, 20 Oct 2009 15:45:56 -0400 In-Reply-To: <4ADDD3CB.40102@gmx.at> (martin rudalics's message of "Tue, 20 Oct 2009 17:14:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to > allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'. I understand. But I also pointed out some changes in semantics (in switch-to-buffer-other-window) that resulted from this choice that might not have been wanted. > So I think it would be easier to have `switch-to-buffer-other-window' > pass the constant 'other-window to `display-buffer' and handle that > case specially there. In principle this means that we'd have to > ignore the `same-window-...' variables and make sure that > `special-display-function' does not return the same window. > `switch-to-buffer-other-frame' then would have to pass 'other-frame to > `display-buffer' and be handled in a similar manner. Maybe that would be a way to go. In any case my suggestion to extend the `other-window' arg to allow other specifications such as same-window, same-frame, etc... was not meant to replace the current functionality but to add some, so that more code can say what it means rather than having to hack around (e.g. using switch-to-buffer where all it really means is "use the current-window if possible and not specified otherwise by the user"). >> It's a concern but not a very serious one: I already consider such uses >> as problems to be fixed. > Well, there's lots of them :-( Not all of them are important, luckily, Stefan From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Glenn Morris Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Oct 2011 23:00:03 +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: To: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.131776914627340 (code B ref 1806); Tue, 04 Oct 2011 23:00:03 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2011 22:59:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBDx4-00076v-5B for submit@debbugs.gnu.org; Tue, 04 Oct 2011 18:59:06 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBDwy-00076T-V5 for 1806@debbugs.gnu.org; Tue, 04 Oct 2011 18:59:01 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RBDvV-0000B3-97; Tue, 04 Oct 2011 18:57:29 -0400 From: Glenn Morris 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> X-Spook: North Korea data haven covert video Rand Corporation X-Ran: L]Td4b_;r54%` (Stefan Monnier's message of "Wed, 14 Jan 2009 13:00:13 -0500") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) This bug is massive, unchanged for two years, and predates the Great Window-Handling Change. I cannot follow what the actual "bug" is here; it seems to have just turned into an extended general discussion. I don't think it is useful to keep this open, so I propose to close this, and ask people to open new bugs focused on whatever specific, individual issues remain. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2011 08:54: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: To: Glenn Morris Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.131780482819146 (code B ref 1806); Wed, 05 Oct 2011 08:54:01 +0000 Received: (at 1806) by debbugs.gnu.org; 5 Oct 2011 08:53:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBNEZ-0004yk-Ce for submit@debbugs.gnu.org; Wed, 05 Oct 2011 04:53:48 -0400 Received: from judo.dreamhost.com ([66.33.216.100] ident=postfix) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBNEW-0004yb-BR for 1806@debbugs.gnu.org; Wed, 05 Oct 2011 04:53:45 -0400 Received: from smarty.dreamhost.com (smarty.dreamhost.com [208.113.175.8]) by judo.dreamhost.com (Postfix) with ESMTP id B188284DACB for <1806@debbugs.gnu.org>; Tue, 4 Oct 2011 17:06:27 -0700 (PDT) Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 307276E8078; Tue, 4 Oct 2011 17:01:27 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id E18E9451C419; Tue, 4 Oct 2011 17:01:25 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> Date: Wed, 05 Oct 2011 02:55:30 +0300 In-Reply-To: (Glenn Morris's message of "Tue, 04 Oct 2011 18:57:29 -0400") Message-ID: <871uusb9an.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > This bug is massive, unchanged for two years, and predates the Great > Window-Handling Change. I cannot follow what the actual "bug" is here; > it seems to have just turned into an extended general discussion. > > I don't think it is useful to keep this open, so I propose to close > this, and ask people to open new bugs focused on whatever specific, > individual issues remain. Actually after Martin introduced a new variable `window-nest' it's possible now to fix this bug in `dired-pop-to-buffer' where window space for the *Marked Files* buffer is stolen from the wrong window in the following configuration: ______________________________________ | ____________________________________ | || || || || || || || || || || || || ||_________________W2_________________|| | ____________________________________ | || || || || ||_________________W3_________________|| |__________________W1__________________| with the following simple patch: === modified file 'lisp/dired.el' --- lisp/dired.el 2011-09-18 20:43:20 +0000 +++ lisp/dired.el 2011-10-04 23:55:18 +0000 @@ -2873,7 +2873,8 @@ (defun dired-mark-prompt (arg files) (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." - (let ((split-window-preferred-function + (let* ((window-nest t) + (split-window-preferred-function (lambda (window) (or (and (let ((split-height-threshold 0)) (window-splittable-p (selected-window))) After fixing it this bug could be closed, and other possibilities (e.g. to display this buffer above the minibuffer etc.) could be postponed to 24.2 and discussed in a new feature request. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2011 22:14: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: To: Juri Linkov Cc: Glenn Morris , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13178528088667 (code B ref 1806); Wed, 05 Oct 2011 22:14:01 +0000 Received: (at 1806) by debbugs.gnu.org; 5 Oct 2011 22:13:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBZiR-0002Fh-Es for submit@debbugs.gnu.org; Wed, 05 Oct 2011 18:13:28 -0400 Received: from vm-emlprdomr-04.its.yale.edu ([130.132.50.145]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBZiQ-0002FV-Dv for 1806@debbugs.gnu.org; Wed, 05 Oct 2011 18:13:26 -0400 Received: from furball (dhcp-128-36-14-81.central.yale.edu [128.36.14.81]) (authenticated bits=0) by vm-emlprdomr-04.its.yale.edu (8.14.4/8.14.4) with ESMTP id p95MDExx022754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Oct 2011 18:13:15 -0400 From: Chong Yidong 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> <871uusb9an.fsf@mail.jurta.org> Date: Wed, 05 Oct 2011 18:13:14 -0400 In-Reply-To: <871uusb9an.fsf@mail.jurta.org> (Juri Linkov's message of "Wed, 05 Oct 2011 02:55:30 +0300") Message-ID: <87y5wz2ikl.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.145 X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Juri Linkov writes: > Actually after Martin introduced a new variable `window-nest' it's > possible now to fix this bug in `dired-pop-to-buffer' where window space > for the *Marked Files* buffer is stolen from the wrong window in the > following configuration: > > ______________________________________ > | ____________________________________ | > || || > || || > ||_________________W2_________________|| > | ____________________________________ | > || || > ||_________________W3_________________|| > |__________________W1__________________| > I assume W2 is showing the Dired buffer in this example? If so, the proposed patch has no effect---W2 is split, so W3 is between the *Marked Files* buffer and the echo area. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2011 23:37:02 +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: To: Chong Yidong Cc: Glenn Morris , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.131785779018819 (code B ref 1806); Wed, 05 Oct 2011 23:37:02 +0000 Received: (at 1806) by debbugs.gnu.org; 5 Oct 2011 23:36:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBb0n-0004tT-67 for submit@debbugs.gnu.org; Wed, 05 Oct 2011 19:36:29 -0400 Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBb0k-0004tK-P5 for 1806@debbugs.gnu.org; Wed, 05 Oct 2011 19:36:28 -0400 Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 76A026E80A7; Wed, 5 Oct 2011 16:36:20 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id F3ED6451C524; Wed, 5 Oct 2011 16:36:18 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> <871uusb9an.fsf@mail.jurta.org> <87y5wz2ikl.fsf@stupidchicken.com> Date: Thu, 06 Oct 2011 02:23:59 +0300 In-Reply-To: <87y5wz2ikl.fsf@stupidchicken.com> (Chong Yidong's message of "Wed, 05 Oct 2011 18:13:14 -0400") Message-ID: <87hb3nc99s.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > I assume W2 is showing the Dired buffer in this example? Yes, W2 is showing the Dired buffer. This is a clearer picture: ______________________________________ | ____________________________________ | || || || || || Dired || || || ||_________________W2_________________|| | ____________________________________ | || || ||_________________W3_________________|| |__________________W1__________________| > If so, the proposed patch has no effect---W2 is split, so W3 is > between the *Marked Files* buffer and the echo area. The problem is that currently `fit-window-to-buffer' in `dired-pop-to-buffer' increases the height of the unrelated window W3 like is shown below: ______________________________________ | ____________________________________ | || Dired || ||_________________W2_________________|| | ____________________________________ | || *Marked Files* || ||_________________W4_________________|| | ____________________________________ | || || || || || || || || ||_________________W3_________________|| |__________________W1__________________| This is very ugly. But when the *Marked Files* window is created when `window-nest' is t, then `fit-window-to-buffer' doesn't enlarge the unrelated window W3 since a new internal window W5 forces it to resize the Dired window W2: ______________________________________ | ____________________________________ | || __________________________________ || ||| ||| ||| Dired ||| |||________________W2________________||| || __________________________________ || ||| *Marked Files* ||| |||________________W4________________||| ||_________________W5_________________|| | ____________________________________ | || || ||_________________W3_________________|| |__________________W1__________________| Unless there is a way to tell `fit-window-to-buffer' to change the height of the upper window instead of the lower window, setting `window-nest' to t can fix `dired-pop-to-buffer' to not resize other unrelated windows. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Oct 2011 02:04:02 +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: To: Juri Linkov Cc: Glenn Morris , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13178666295063 (code B ref 1806); Thu, 06 Oct 2011 02:04:02 +0000 Received: (at 1806) by debbugs.gnu.org; 6 Oct 2011 02:03:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBdJN-0001Jb-7X for submit@debbugs.gnu.org; Wed, 05 Oct 2011 22:03:49 -0400 Received: from vm-emlprdomr-02.its.yale.edu ([130.132.50.143]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBdJL-0001JQ-Ct for 1806@debbugs.gnu.org; Wed, 05 Oct 2011 22:03:48 -0400 Received: from furball (dhcp-128-36-14-81.central.yale.edu [128.36.14.81]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id p9623Zng025215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Oct 2011 22:03:35 -0400 From: Chong Yidong 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> <871uusb9an.fsf@mail.jurta.org> <87y5wz2ikl.fsf@stupidchicken.com> <87hb3nc99s.fsf@mail.jurta.org> Date: Wed, 05 Oct 2011 22:03:34 -0400 In-Reply-To: <87hb3nc99s.fsf@mail.jurta.org> (Juri Linkov's message of "Thu, 06 Oct 2011 02:23:59 +0300") Message-ID: <87d3ea3mh5.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Juri Linkov writes: > The problem is that currently `fit-window-to-buffer' in > `dired-pop-to-buffer' increases the height of the unrelated window W3 > > This is very ugly. OK, but (i) this seems unrelated to the issue you originally raised in this bug, and (ii) surely this is not special to Dired, so instead of changing dired-pop-to-buffer, why not just have the user customize window-nest to t if the user wants the behavior you describe? From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Oct 2011 15:24: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: To: Chong Yidong Cc: Glenn Morris , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.131791460515139 (code B ref 1806); Thu, 06 Oct 2011 15:24:01 +0000 Received: (at 1806) by debbugs.gnu.org; 6 Oct 2011 15:23:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBpnA-0003w8-Vn for submit@debbugs.gnu.org; Thu, 06 Oct 2011 11:23:25 -0400 Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RBpn9-0003w1-Fb for 1806@debbugs.gnu.org; Thu, 06 Oct 2011 11:23:24 -0400 Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 673846E8081; Thu, 6 Oct 2011 08:23:13 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 56AF8451C527; Thu, 6 Oct 2011 08:23:11 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> <871uusb9an.fsf@mail.jurta.org> <87y5wz2ikl.fsf@stupidchicken.com> <87hb3nc99s.fsf@mail.jurta.org> <87d3ea3mh5.fsf@stupidchicken.com> Date: Thu, 06 Oct 2011 18:20:04 +0300 In-Reply-To: <87d3ea3mh5.fsf@stupidchicken.com> (Chong Yidong's message of "Wed, 05 Oct 2011 22:03:34 -0400") Message-ID: <87obxuw3iz.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > OK, but (i) this seems unrelated to the issue you originally raised in > this bug, It fixes the issue I raised in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1806#65 that describes the remaining problem with the current behavior of Dired. We were unable to fix it before implementing `window-nest'. > and (ii) surely this is not special to Dired, so instead of > changing dired-pop-to-buffer, why not just have the user customize > window-nest to t if the user wants the behavior you describe? I think it's a plain bug to resize unrelated windows, not a behavior some users might prefer. As for setting `window-nest' to t by default, I don't know how it would affect other window-related functionality. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Oct 2011 20:55:02 +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: To: Chong Yidong Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.131828008718643 (code B ref 1806); Mon, 10 Oct 2011 20:55:02 +0000 Received: (at 1806) by debbugs.gnu.org; 10 Oct 2011 20:54:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RDMs2-0004qd-AA for submit@debbugs.gnu.org; Mon, 10 Oct 2011 16:54:47 -0400 Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RDMry-0004qU-HC for 1806@debbugs.gnu.org; Mon, 10 Oct 2011 16:54:44 -0400 Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 6D5776E8088; Mon, 10 Oct 2011 13:54:28 -0700 (PDT) Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 855D6451C546; Mon, 10 Oct 2011 13:54:27 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <87d4ezuw6w.fsf@jurta.org> <4964CB72.1090605@gmx.at> <49665326.8060607@gmx.at> <4967193D.3060206@gmx.at> <496DF4C7.70800@gmx.at> <871uusb9an.fsf@mail.jurta.org> <87y5wz2ikl.fsf@stupidchicken.com> <87hb3nc99s.fsf@mail.jurta.org> <87d3ea3mh5.fsf@stupidchicken.com> <87obxuw3iz.fsf@mail.jurta.org> Date: Mon, 10 Oct 2011 23:51:34 +0300 In-Reply-To: <87obxuw3iz.fsf@mail.jurta.org> (Juri Linkov's message of "Thu, 06 Oct 2011 18:20:04 +0300") Message-ID: <877h4c604p.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > I think it's a plain bug to resize unrelated windows, > not a behavior some users might prefer. Is it OK to fix it? I feel ashamed to see in e.g. today's podcast at http://kennym.github.com/blog/2011/10/10/emacs-dired-mode-the-basics/ (from 5:50 to 6:15) that we have not yet fixed this ugly bug. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Sep 2012 13:27: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134832037914482 (code B ref 1806); Sat, 22 Sep 2012 13:27:01 +0000 Received: (at 1806) by debbugs.gnu.org; 22 Sep 2012 13:26:19 +0000 Received: from localhost ([127.0.0.1]:48340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFPis-0003lV-3Y for submit@debbugs.gnu.org; Sat, 22 Sep 2012 09:26:18 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:45867) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TFPin-0003lJ-Hu for 1806@debbugs.gnu.org; Sat, 22 Sep 2012 09:26:16 -0400 Received: (qmail invoked by alias); 22 Sep 2012 13:24:29 -0000 Received: from 62-47-47-153.adsl.highway.telekom.at (EHLO [62.47.47.153]) [62.47.47.153] by mail.gmx.net (mp038) with SMTP; 22 Sep 2012 15:24:29 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+8oT5kEKm8oZ2iqAUL1De+h6ZgGz18jBZEVYGLuu wApeJktucVilrC Message-ID: <505DBC23.5040907@gmx.at> Date: Sat, 22 Sep 2012 15:24:51 +0200 From: martin rudalics MIME-Version: 1.0 References: <87r63gzcap.fsf@jurta.org> In-Reply-To: <87r63gzcap.fsf@jurta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > After 2008-12-11 change to window.el and dired.el that fixed the bug #1488, > I have difficulties using dired. > > Before this change, running a dired operation on many files displayed > a pop-up window *below* the dired buffer and immediately *above* the > minibuffer. This is the most convenient place to display a list of > file names, because it is near the minibuffer where the user types more > input for the command (a shell command or a directory to copy files to). This should now work again as before. If the dired buffer is not immediately *above* the minibuffer, the file names are shown below the dired buffer. I also introduced a new default value for `window-combination-limit' which should assure that fitting the window to the buffer does not steal space from any window below. > I've just looked at the old behavior from the December CVS state, > and noticed that it behaved more conveniently than we are currently > discussing. It displayed a list of files immediately above the > minibuffer. This is convenient because when the minibuffer says: > > ! on * [5 files]: > > then a list of these 5 files is very near above, so there is no need > to search for this list elsewhere on the current frame. Maybe we > should have a special function to display a buffer above the minibuffer > (e.g. `pop-to-buffer-above-minibuffer')? The action function `display-buffer-at-bottom' should do that so people who prefer this are able to do the necessary customizations. If there's anything missing please tell me. Thanks, martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Sep 2012 00:18:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134835947313847 (code B ref 1806); Sun, 23 Sep 2012 00:18:02 +0000 Received: (at 1806) by debbugs.gnu.org; 23 Sep 2012 00:17:53 +0000 Received: from localhost ([127.0.0.1]:49849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFZtR-0003bH-8w for submit@debbugs.gnu.org; Sat, 22 Sep 2012 20:17:53 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:56708 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFZtP-0003bB-Pz for 1806@debbugs.gnu.org; Sat, 22 Sep 2012 20:17:52 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 21AD0451CCEA; Sat, 22 Sep 2012 17:16:04 -0700 (PDT) From: Juri Linkov Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <505DBC23.5040907@gmx.at> Date: Sun, 23 Sep 2012 02:54:30 +0300 In-Reply-To: <505DBC23.5040907@gmx.at> (martin rudalics's message of "Sat, 22 Sep 2012 15:24:51 +0200") Message-ID: <87y5k1lhn6.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > If there's anything missing please tell me. Thanks for enhancements. There is one unfortunate regression where a large almost empty window is displayed with just two lines instead of a narrow window like in previous versions. One test case is typing !, or C, or R in Dired on two marked files when dired-shrink-to-fit is t. dired-pop-to-buffer should take care of this, but it doesn't work. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Sep 2012 09:25: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134839224428499 (code B ref 1806); Sun, 23 Sep 2012 09:25:01 +0000 Received: (at 1806) by debbugs.gnu.org; 23 Sep 2012 09:24:04 +0000 Received: from localhost ([127.0.0.1]:50250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFiPz-0007Pb-E8 for submit@debbugs.gnu.org; Sun, 23 Sep 2012 05:24:03 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:49365) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TFiPx-0007P8-Ae for 1806@debbugs.gnu.org; Sun, 23 Sep 2012 05:24:01 -0400 Received: (qmail invoked by alias); 23 Sep 2012 09:22:12 -0000 Received: from 62-47-34-71.adsl.highway.telekom.at (EHLO [62.47.34.71]) [62.47.34.71] by mail.gmx.net (mp027) with SMTP; 23 Sep 2012 11:22:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18EHssMc4YEAsZ3YSH7mlrpoX3QllDQNgzOARh0FV hR2tWFIeE5nbnf Message-ID: <505ED4BB.3030103@gmx.at> Date: Sun, 23 Sep 2012 11:22:03 +0200 From: martin rudalics MIME-Version: 1.0 References: <87r63gzcap.fsf@jurta.org> <505DBC23.5040907@gmx.at> <87y5k1lhn6.fsf@mail.jurta.org> In-Reply-To: <87y5k1lhn6.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Thanks for enhancements. There is one unfortunate regression > where a large almost empty window is displayed with just two lines > instead of a narrow window like in previous versions. One test case > is typing !, or C, or R in Dired on two marked files when dired-shrink-to-fit > is t. dired-pop-to-buffer should take care of this, but it doesn't work. `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is no longer consulted. You have to enable `temp-buffer-resize-mode'. If you really insist on handling dired's pop-up buffers separately, I can do that by binding `temp-buffer-resize-mode' appropriately, but I'd rather have a common solution for handling all temporary windows in the same manner. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Sep 2012 08:30: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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13484753782320 (code B ref 1806); Mon, 24 Sep 2012 08:30:01 +0000 Received: (at 1806) by debbugs.gnu.org; 24 Sep 2012 08:29:38 +0000 Received: from localhost ([127.0.0.1]:52080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG42r-0000bN-PX for submit@debbugs.gnu.org; Mon, 24 Sep 2012 04:29:38 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:34760 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG42p-0000bD-Ks for 1806@debbugs.gnu.org; Mon, 24 Sep 2012 04:29:36 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 56D88451CCC3; Mon, 24 Sep 2012 01:27:41 -0700 (PDT) From: Juri Linkov Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <505DBC23.5040907@gmx.at> <87y5k1lhn6.fsf@mail.jurta.org> <505ED4BB.3030103@gmx.at> Date: Mon, 24 Sep 2012 11:22:12 +0300 In-Reply-To: <505ED4BB.3030103@gmx.at> (martin rudalics's message of "Sun, 23 Sep 2012 11:22:03 +0200") Message-ID: <87txunj0ej.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > You have to enable `temp-buffer-resize-mode'. I tried to enable `temp-buffer-resize-mode', and with a large list of files it seems to ignore `window-combination-limit', i.e. the temporary window steals space from the window below. A sample test case is: `M-x temp-buffer-resize-mode', in a Dired window `C-x 3 C-x 2 m m m ...' (mark 100 files), `!' (`dired-do-shell-command') steals space from the window below, and `C-g' doesn't restore the initial window configuration. Is this because `window-combination-limit' is not taken into account? I see that its default value is `temp-buffer-resize', the same unchanged value used in the test above. 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 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. > `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is > no longer consulted. > If you really insist on handling dired's pop-up buffers separately, > I can do that by binding `temp-buffer-resize-mode' appropriately, but > I'd rather have a common solution for handling all temporary windows > in the same manner. There is nothing wrong when a package uses a local variable that changes the general behavior. So `dired-mark-pop-up' could still call `dired-pop-to-buffer' that will bind `temp-buffer-resize-mode' according to the value of `dired-shrink-to-fit'. This assumes that `dired-pop-to-buffer' is the right name for this functionality. Otherwise, it could be marked obsolete. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Sep 2012 09:43:02 +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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13484797778594 (code B ref 1806); Mon, 24 Sep 2012 09:43:02 +0000 Received: (at 1806) by debbugs.gnu.org; 24 Sep 2012 09:42:57 +0000 Received: from localhost ([127.0.0.1]:52127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG5Bp-0002EZ-5N for submit@debbugs.gnu.org; Mon, 24 Sep 2012 05:42:57 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:46576) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TG5Bm-0002ER-JA for 1806@debbugs.gnu.org; Mon, 24 Sep 2012 05:42:55 -0400 Received: (qmail invoked by alias); 24 Sep 2012 09:40:26 -0000 Received: from 62-47-46-191.adsl.highway.telekom.at (EHLO [62.47.46.191]) [62.47.46.191] by mail.gmx.net (mp017) with SMTP; 24 Sep 2012 11:40:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+h40BqcZOh314J4oFKYuDyyw8yMUyB3LdYRVrUCL oDW+Dyi6VmeWYa Message-ID: <50602A8D.6010203@gmx.at> Date: Mon, 24 Sep 2012 11:40:29 +0200 From: martin rudalics MIME-Version: 1.0 References: <87r63gzcap.fsf@jurta.org> <505DBC23.5040907@gmx.at> <87y5k1lhn6.fsf@mail.jurta.org> <505ED4BB.3030103@gmx.at> <87txunj0ej.fsf@mail.jurta.org> In-Reply-To: <87txunj0ej.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I tried to enable `temp-buffer-resize-mode', and with a large list of files > it seems to ignore `window-combination-limit', i.e. the temporary window > steals space from the window below. A sample test case is: > `M-x temp-buffer-resize-mode', in a Dired window `C-x 3 C-x 2 m m m ...' > (mark 100 files), `!' (`dired-do-shell-command') steals space from the > window below, and `C-g' doesn't restore the initial window configuration. > > Is this because `window-combination-limit' is not taken into account? > I see that its default value is `temp-buffer-resize', the same unchanged > value used in the test above. No. 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? > 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? > 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? >> `dired-pop-to-buffer' is no longer called and `dired-shrink-to-fit' is >> no longer consulted. >> If you really insist on handling dired's pop-up buffers separately, >> I can do that by binding `temp-buffer-resize-mode' appropriately, but >> I'd rather have a common solution for handling all temporary windows >> in the same manner. > > There is nothing wrong when a package uses a local variable > that changes the general behavior. So `dired-mark-pop-up' could still > call `dired-pop-to-buffer' that will bind `temp-buffer-resize-mode' > according to the value of `dired-shrink-to-fit'. This assumes that > `dired-pop-to-buffer' is the right name for this functionality. > Otherwise, it could be marked obsolete. 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. 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? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place 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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134856119521150 (code B ref 1806); Tue, 25 Sep 2012 08:20:01 +0000 Received: (at 1806) by debbugs.gnu.org; 25 Sep 2012 08:19:55 +0000 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 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 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) From: Juri Linkov Organization: JURTA 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> Date: Tue, 25 Sep 2012 11:05:05 +0300 In-Reply-To: <50602A8D.6010203@gmx.at> (martin rudalics's message of "Mon, 24 Sep 2012 11:40:29 +0200") Message-ID: <8739261q8h.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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? From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Sep 2012 10:02: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134856727829990 (code B ref 1806); Tue, 25 Sep 2012 10:02:01 +0000 Received: (at 1806) by debbugs.gnu.org; 25 Sep 2012 10:01:18 +0000 Received: from localhost ([127.0.0.1]:54504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGRx8-0007nf-1c for submit@debbugs.gnu.org; Tue, 25 Sep 2012 06:01:18 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:37626) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGRx6-0007nY-Fu for 1806@debbugs.gnu.org; Tue, 25 Sep 2012 06:01:17 -0400 Received: (qmail invoked by alias); 25 Sep 2012 09:59:16 -0000 Received: from 62-47-32-73.adsl.highway.telekom.at (EHLO [62.47.32.73]) [62.47.32.73] by mail.gmx.net (mp035) with SMTP; 25 Sep 2012 11:59:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/tHvJF4yntzgRLo/BSXYku2Uc/L6AOJxT0zON0Zz eNzhtZU1JaG7uX Message-ID: <5061807D.1010401@gmx.at> Date: Tue, 25 Sep 2012 11:59:25 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> In-Reply-To: <8739261q8h.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> 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. The problem is that we don't know beforehand how small the number of files is going to be and how much space `fit-window-to-buffer' will make out of it. We had that already a number of times ... > 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. Do we really care? I think that users who mark a large number of files usually don't do that with other windows around. OTOH we could try to make `fit-window-to-buffer' always affect only windows in the same combination. Or do so for `temp-buffer-resize-mode' only. > If now is possible to split the root window immediately, then maybe > it would be better to try doing so. Just that splitting the root will resize all windows proportionally and I just have another thread were people don't like that (recall that you want to do that for a large number of files). > Then a new function with a name like `with-temp-buffer-window-pop-up' > might be necessary to use it in Dired, Proced, VC VC currently doesn't use `temp-buffer-resize-mode' and I'm not sure whether we should use `with-temp-buffer-window' for it. > 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. We can't. Too many people don't like to automatically fit windows to their buffers. They must be able to turn that off. > 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? It was earlier via `special-display-buffer-names' and `special-display-regexps' and is now via `display-buffer-alist'. You just have to write the corresponding buffer display function. The problem is that nobody liked my earlier approach to combine specifiers. So you now have to code within these functions how you want to display the buffer and possibly resize its window. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 03:20:02 +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: To: martin rudalics Cc: Juri Linkov , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13486295514153 (code B ref 1806); Wed, 26 Sep 2012 03:20:02 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 03:19:11 +0000 Received: from localhost ([127.0.0.1]:56020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGi9W-00014v-RA for submit@debbugs.gnu.org; Tue, 25 Sep 2012 23:19:11 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:65494) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGi9T-00014l-UE for 1806@debbugs.gnu.org; Tue, 25 Sep 2012 23:19:08 -0400 Received: by pbbro8 with SMTP id ro8so1189085pbb.3 for <1806@debbugs.gnu.org>; Tue, 25 Sep 2012 20:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=/D3+OXGiwxiMOwAo8vueVTG8en6OpnPdkBghd6rIJD0=; b=YghRyhBmQv1moyK8hRXm/Max7RCUXY//8ZSoIjFb1rb3T1rSSLnw0tk07urIozizGj WfwbxIESxXFZUbofQv1vZEdKKjieHVIWrlPZdG09v8nNTTMnLlmR8NgEOdl0GvxqHZD5 EozyFEOuWrcNeF5T/ijkEqr8eAHMMMpRUHYWvTbzyBPb+PFpaqHQ6u4EZnk065PQ5N5T HRW6lIMvqal1XH8mZwh22PvibJKOL2rlw1RKO1Xn6vfRfFp6z26cwjnza9i4LX156u9B n0JQpSrv6gc5oe7mOmCpZoRLN+cbAEIou7LgAlvCMdS+5N/HoW93/6llkQiMgg9Uf5Uj uvQg== Received: by 10.66.84.6 with SMTP id u6mr45337994pay.75.1348629424416; Tue, 25 Sep 2012 20:17:04 -0700 (PDT) Received: from ulysses ([155.69.16.255]) by mx.google.com with ESMTPS id i1sm1134245pay.26.2012.09.25.20.17.00 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 20:17:03 -0700 (PDT) From: Chong Yidong 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> Date: Wed, 26 Sep 2012 11:16:58 +0800 In-Reply-To: <50602A8D.6010203@gmx.at> (martin rudalics's message of "Mon, 24 Sep 2012 11:40:29 +0200") Message-ID: <87y5jxfp79.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) martin rudalics writes: > Note that I have added an option `temp-buffer-resize-regexps' which can > be used to turn off resizing in selected buffers. What is the rationale for this change? I can't find any discussion about this on emacs-devel or the bug list, but maybe I missed it. I'm not enthusiastic about the existence of temp-buffer-resize-mode in the first place. It's a bad concept, since it creates a difference between "temporary buffers" and other kinds of buffers displayed via display-buffer. But there are no guidelines for when such a difference should exist. So adding more knobs onto temp-buffer-resize-mode is a step in the wrong direction, IMO. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 06:51:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134864222822743 (code B ref 1806); Wed, 26 Sep 2012 06:51:02 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 06:50:28 +0000 Received: from localhost ([127.0.0.1]:56199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGlRz-0005ul-QH for submit@debbugs.gnu.org; Wed, 26 Sep 2012 02:50:28 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:45761 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGlRw-0005uc-7K for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 02:50:26 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 8C327451CD0D; Tue, 25 Sep 2012 23:48:16 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> Date: Wed, 26 Sep 2012 09:24:00 +0300 In-Reply-To: <5061807D.1010401@gmx.at> (martin rudalics's message of "Tue, 25 Sep 2012 11:59:25 +0200") Message-ID: <87pq59z3nr.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Just that splitting the root will resize all windows proportionally and > I just have another thread were people don't like that (recall that you > want to do that for a large number of files). Yes, there are more problems with `display-buffer-at-bottom' that could be fixed later. This is why I don't propose to make it default now. But still we should fix the problems with the current default action `display-buffer-below-selected' because they are regressions. >> Then a new function with a name like `with-temp-buffer-window-pop-up' >> might be necessary to use it in Dired, Proced, VC > > VC currently doesn't use `temp-buffer-resize-mode' and I'm not sure > whether we should use `with-temp-buffer-window' for it. Like Dired and Proced, VC shrinks the window to fit the buffer in `log-edit-show-files', so it could use `with-temp-buffer-window' too if it will retain the original behavior in the affected commands. > It was earlier via `special-display-buffer-names' and > `special-display-regexps' and is now via `display-buffer-alist'. You > just have to write the corresponding buffer display function. The > problem is that nobody liked my earlier approach to combine specifiers. > So you now have to code within these functions how you want to display > the buffer and possibly resize its window. There is no need to combine specifiers and no need to add `temp-buffer-resize-regexps'. In your current implementation it's perfectly possible to use the following call in `dired-mark-pop-up': (with-temp-buffer-window buffer (cons 'display-buffer-below-selected '((fit-window-to-buffer . t))) ... and to add the following code to `display-buffer-below-selected' (copied and adapted from `dired-pop-to-buffer'): (defun display-buffer-below-selected (buffer alist) "Try displaying BUFFER in a window below the selected window. This either splits the selected window or reuses the window below the selected one." (let (window) (or (and (not (frame-parameter nil 'unsplittable)) (setq window (window--try-to-split-window (selected-window))) (window--display-buffer buffer window 'window display-buffer-mark-dedicated)) (and (setq window (window-in-direction 'below)) (not (window-dedicated-p window)) (window--display-buffer buffer window 'reuse display-buffer-mark-dedicated))) ;; See Bug#12281. (set-window-start window (point-min)) ;; If fit-window-to-buffer is t, make its window fit its contents. (when (cdr (assq 'fit-window-to-buffer alist)) ;; Try to not delete window when we want to display less than ;; `window-min-height' lines. (fit-window-to-buffer window nil 1)) window)) > Too many people don't like to automatically fit windows to > their buffers. They must be able to turn that off. With the fixes above, users will be able to turn that off by customizing `display-buffer-alist' to the following value (this should be done via the Customization UI, but `setq' is used below for testing purposes): (setq display-buffer-alist '(("Marked Files" . (display-buffer-below-selected (fit-window-to-buffer . nil))))) From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 08:49:02 +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: To: Chong Yidong Cc: Juri Linkov , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13486492924365 (code B ref 1806); Wed, 26 Sep 2012 08:49:02 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 08:48:12 +0000 Received: from localhost ([127.0.0.1]:56318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGnHv-00018M-Ls for submit@debbugs.gnu.org; Wed, 26 Sep 2012 04:48:12 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:54087) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGnHt-00018E-N8 for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 04:48:10 -0400 Received: (qmail invoked by alias); 26 Sep 2012 08:48:10 -0000 Received: from 62-47-47-61.adsl.highway.telekom.at (EHLO [62.47.47.61]) [62.47.47.61] by mail.gmx.net (mp027) with SMTP; 26 Sep 2012 10:48:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/r39UiMSnrY5lDxOEqro+YTSV7O2JrZWXn9QzbOe JRbzknPwvJNYv5 Message-ID: <5062C147.2080600@gmx.at> Date: Wed, 26 Sep 2012 10:48:07 +0200 From: martin rudalics MIME-Version: 1.0 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> <87y5jxfp79.fsf@gnu.org> In-Reply-To: <87y5jxfp79.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Note that I have added an option `temp-buffer-resize-regexps' which can >> be used to turn off resizing in selected buffers. > > What is the rationale for this change? I can't find any discussion > about this on emacs-devel or the bug list, but maybe I missed it. The problem has been discussed in the thread for bug#1806 and in a thread you started about window shrinking via VC-diff. There it has been asked for a way to switch off auto-resizing. My rationale is to do all `fit-window-to-buffer' stuff under `temp-buffer-resize-mode' and allow tweaking this in a uniform manner for individual buffers. > I'm not enthusiastic about the existence of temp-buffer-resize-mode in > the first place. It's a bad concept, since it creates a difference > between "temporary buffers" and other kinds of buffers displayed via > display-buffer. Then we probably should change that concept. My intention was to fit windows even when `display-buffer' is not called. For example, after certain changes of the buffer contents, without asking for a redisplay via `display-buffer'. > But there are no guidelines for when such a difference > should exist. So adding more knobs onto temp-buffer-resize-mode is a > step in the wrong direction, IMO. I have no opinion on this and can do whatever people want. But bug#1806 should be eventually closed in some way. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 08:49:03 +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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13486493374418 (code B ref 1806); Wed, 26 Sep 2012 08:49:03 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 08:48:57 +0000 Received: from localhost ([127.0.0.1]:56321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGnIe-00019C-JM for submit@debbugs.gnu.org; Wed, 26 Sep 2012 04:48:56 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:48273) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGnIb-000194-Iy for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 04:48:54 -0400 Received: (qmail invoked by alias); 26 Sep 2012 08:48:55 -0000 Received: from 62-47-47-61.adsl.highway.telekom.at (EHLO [62.47.47.61]) [62.47.47.61] by mail.gmx.net (mp071) with SMTP; 26 Sep 2012 10:48:55 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18FNoAgAlUF+klzZGo7NvNwINUWxRvy5WC5W3L4uy 1LUl6nXlGy1u8J Message-ID: <5062C173.3050402@gmx.at> Date: Wed, 26 Sep 2012 10:48:51 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> In-Reply-To: <87pq59z3nr.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Like Dired and Proced, VC shrinks the window to fit the buffer in > `log-edit-show-files', so it could use `with-temp-buffer-window' too > if it will retain the original behavior in the affected commands. Maybe. But when a buffer already exists, `with-temp-buffer-window' is not suitable since it erases its contents. > There is no need to combine specifiers and no need to add > `temp-buffer-resize-regexps'. In your current implementation > it's perfectly possible to use the following call in `dired-mark-pop-up': > > (with-temp-buffer-window > buffer > (cons 'display-buffer-below-selected > '((fit-window-to-buffer . t))) > ... > > and to add the following code to `display-buffer-below-selected' > (copied and adapted from `dired-pop-to-buffer'): > > (defun display-buffer-below-selected (buffer alist) > "Try displaying BUFFER in a window below the selected window. > This either splits the selected window or reuses the window below > the selected one." > (let (window) > (or (and (not (frame-parameter nil 'unsplittable)) > (setq window (window--try-to-split-window (selected-window))) > (window--display-buffer > buffer window 'window display-buffer-mark-dedicated)) > (and (setq window (window-in-direction 'below)) > (not (window-dedicated-p window)) > (window--display-buffer > buffer window 'reuse display-buffer-mark-dedicated))) > ;; See Bug#12281. > (set-window-start window (point-min)) > ;; If fit-window-to-buffer is t, make its window fit its contents. > (when (cdr (assq 'fit-window-to-buffer alist)) > ;; Try to not delete window when we want to display less than > ;; `window-min-height' lines. > (fit-window-to-buffer window nil 1)) > window)) How would we handle the case where `window--try-to-split-window' fails for the selected window and some other window (like the frame's bottom window) gets split? >> Too many people don't like to automatically fit windows to >> their buffers. They must be able to turn that off. > > With the fixes above, users will be able to turn that off by customizing > `display-buffer-alist' to the following value (this should be done via the > Customization UI, but `setq' is used below for testing purposes): > > (setq display-buffer-alist '(("Marked Files" . > (display-buffer-below-selected > (fit-window-to-buffer . nil))))) And how would they handle the frame bottom window case sketched above? martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 10:12:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134865427011522 (code B ref 1806); Wed, 26 Sep 2012 10:12:02 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 10:11:10 +0000 Received: from localhost ([127.0.0.1]:56365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGoaD-0002zn-R2 for submit@debbugs.gnu.org; Wed, 26 Sep 2012 06:11:09 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:54214 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGoaB-0002zf-3i for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 06:11:08 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id C371C451CD11; Wed, 26 Sep 2012 03:11:07 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> Date: Wed, 26 Sep 2012 13:10:00 +0300 In-Reply-To: <5062C173.3050402@gmx.at> (martin rudalics's message of "Wed, 26 Sep 2012 10:48:51 +0200") Message-ID: <87r4ppxfgm.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > How would we handle the case where `window--try-to-split-window' fails > for the selected window and some other window (like the frame's bottom > window) gets split? This case is exceptional, but maybe handling of the `fit-window-to-buffer' specifier could be added to some other actions where it makes sense? >> (setq display-buffer-alist '(("Marked Files" . >> (display-buffer-below-selected >> (fit-window-to-buffer . nil))))) > > And how would they handle the frame bottom window case sketched above? With (setq display-buffer-alist '(("Marked Files" . (nil (fit-window-to-buffer . nil))))) From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 11:04:02 +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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134865740716341 (code B ref 1806); Wed, 26 Sep 2012 11:04:02 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 11:03:27 +0000 Received: from localhost ([127.0.0.1]:56407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGpOo-0004FV-T4 for submit@debbugs.gnu.org; Wed, 26 Sep 2012 07:03:27 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:40469) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGpOm-0004FO-H7 for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 07:03:25 -0400 Received: (qmail invoked by alias); 26 Sep 2012 11:03:25 -0000 Received: from 62-47-47-61.adsl.highway.telekom.at (EHLO [62.47.47.61]) [62.47.47.61] by mail.gmx.net (mp027) with SMTP; 26 Sep 2012 13:03:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+wcVc1wAawdUUdVxQknmPdJQnncYsUJVx3a8J/qX oaezHbj0Qajr5w Message-ID: <5062E0FA.50701@gmx.at> Date: Wed, 26 Sep 2012 13:03:22 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> In-Reply-To: <87r4ppxfgm.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> How would we handle the case where `window--try-to-split-window' fails >> for the selected window and some other window (like the frame's bottom >> window) gets split? > > This case is exceptional, but maybe handling of the `fit-window-to-buffer' > specifier could be added to some other actions where it makes sense? > >>> (setq display-buffer-alist '(("Marked Files" . >>> (display-buffer-below-selected >>> (fit-window-to-buffer . nil))))) >> And how would they handle the frame bottom window case sketched above? > > With (setq display-buffer-alist > '(("Marked Files" . (nil (fit-window-to-buffer . nil))))) I see. My knowledge of `display-buffer-alist' is certainly much worse than yours. Could you patch this along these lines? I think Chong will agree, if we only can get rid of the `temp-buffer-resize-regexps' stuff. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2012 11:23: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: To: martin rudalics Cc: Chong Yidong , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134865857117989 (code B ref 1806); Wed, 26 Sep 2012 11:23:01 +0000 Received: (at 1806) by debbugs.gnu.org; 26 Sep 2012 11:22:51 +0000 Received: from localhost ([127.0.0.1]:56415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGphb-0004g5-KW for submit@debbugs.gnu.org; Wed, 26 Sep 2012 07:22:51 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:39218) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGphY-0004fx-Qh for 1806@debbugs.gnu.org; Wed, 26 Sep 2012 07:22:49 -0400 Received: by bkcjc3 with SMTP id jc3so250486bkc.3 for <1806@debbugs.gnu.org>; Wed, 26 Sep 2012 04:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Tchzc1kGHaUkyuUELoLab3txh7SKgaTylIVSCH5qnrc=; b=BZVp7I+xTS8v7BGBJpZRYK6eUWSew9M6U/r7hKRvMRir3cSMM55OXnVqqrl5TvIRFu dqZdk6V1fLV5YC+3QSQC+0SBZ2UigGEV3IRkWT9AU1Bp5k/l5RTune5wGIfi0UhYLVjE j1K+mAX0lF8gOiwgTB0azprl5fzp/jSeJQtphGrd0DM1G/lDAgHvZvoM8FPOEsB6ZfHN TAxXHR14GHWFhICUnoXSkci472tlvicBQqlcPhYMBWdUYgH4nq4T/2fwmJ/ykUE/k/W0 RK4q9eQCzm304atGyseGX/WwZutTGFpNkjttn4UexcwQvbXzIIwbizTRwHcMpvc0FrfX 5o8w== Received: by 10.204.9.149 with SMTP id l21mr213970bkl.57.1348658569997; Wed, 26 Sep 2012 04:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.41.201 with HTTP; Wed, 26 Sep 2012 04:22:08 -0700 (PDT) In-Reply-To: <5062C147.2080600@gmx.at> 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> <87y5jxfp79.fsf@gnu.org> <5062C147.2080600@gmx.at> From: Juanma Barranquero Date: Wed, 26 Sep 2012 13:22:08 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Wed, Sep 26, 2012 at 10:48 AM, martin rudalics wrote: > Then we probably should change that concept. My intention was to fit > windows even when `display-buffer' is not called. For example, after > certain changes of the buffer contents, without asking for a redisplay > via `display-buffer'. FWIW, I enthusiastically support any way to make temporary windows resize automa[tg]ically to fit the buffer. Juanma From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Sep 2012 08:06:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13487331064214 (code B ref 1806); Thu, 27 Sep 2012 08:06:02 +0000 Received: (at 1806) by debbugs.gnu.org; 27 Sep 2012 08:05:06 +0000 Received: from localhost ([127.0.0.1]:57952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TH95m-00015u-6B for submit@debbugs.gnu.org; Thu, 27 Sep 2012 04:05:06 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:58042 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TH95j-00015m-3H for 1806@debbugs.gnu.org; Thu, 27 Sep 2012 04:05:04 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 39BE2451CD09; Thu, 27 Sep 2012 01:04:58 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> Date: Thu, 27 Sep 2012 11:01:10 +0300 In-Reply-To: <5062E0FA.50701@gmx.at> (martin rudalics's message of "Wed, 26 Sep 2012 13:03:22 +0200") Message-ID: <87sja3rj1p.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I see. My knowledge of `display-buffer-alist' is certainly much worse > than yours. Could you patch this along these lines? I think Chong will > agree, if we only can get rid of the `temp-buffer-resize-regexps' stuff. Of course I know less than you. I don't know what problems you intended to fix with new options that you implemented. Particularly I didn't know that you intended to use `temp-buffer-resize-mode' in buffers displayed without `display-buffer'. What I wanted to do is just to help you to fix 2 regressions in Dired to be able to close bug#1806. One regression is related to the need to use `fit-window-to-buffer' and `set-window-start' like in the previously used `dired-pop-to-buffer'. The second regression is that the value `t' of `window-combination-limit' is ignored, so `fit-window-to-buffer' steals space from the window below. I have no idea how to fix that. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Sep 2012 17:33: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13487671315660 (code B ref 1806); Thu, 27 Sep 2012 17:33:01 +0000 Received: (at 1806) by debbugs.gnu.org; 27 Sep 2012 17:32:11 +0000 Received: from localhost ([127.0.0.1]:59150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THHwZ-0001TE-A9 for submit@debbugs.gnu.org; Thu, 27 Sep 2012 13:32:11 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:42579) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1THHwX-0001T3-92 for 1806@debbugs.gnu.org; Thu, 27 Sep 2012 13:32:10 -0400 Received: (qmail invoked by alias); 27 Sep 2012 17:32:02 -0000 Received: from 62-47-32-57.adsl.highway.telekom.at (EHLO [62.47.32.57]) [62.47.32.57] by mail.gmx.net (mp029) with SMTP; 27 Sep 2012 19:32:02 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19dnuJtGXhddhH6GWVZ+jcC1eHGechca2+cjw4su5 ReAz2XIXxALAEh Message-ID: <50648DAF.5070409@gmx.at> Date: Thu, 27 Sep 2012 19:32:31 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> In-Reply-To: <87sja3rj1p.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Of course I know less than you. I don't know what problems you > intended to fix with new options that you implemented. Particularly > I didn't know that you intended to use `temp-buffer-resize-mode' in > buffers displayed without `display-buffer'. This has no relation to the problem at hand. It would have been an easy fix for functions that currently don't use `with-output-to-temp-buffer'. > What I wanted to do > is just to help you to fix 2 regressions in Dired to be able to > close bug#1806. One regression is related to the need to use > `fit-window-to-buffer' I don't understand you. When `temp-buffer-resize-mode' is enabled, I try to do `fit-window-to-buffer'. > and `set-window-start' like in the previously > used `dired-pop-to-buffer'. You never talked about `set-window-start' in the present context before. `with-temp-buffer-window' goes to `point-min' in the buffer it displays - is that not sufficient? > The second regression is that the value `t' > of `window-combination-limit' is ignored, I don't understand again. If `window-combination-limit' is t it remains t and is obeyed. If it's 'temp-buffer or 'temp-buffer-resize it changes its value to t. > so `fit-window-to-buffer' > steals space from the window below. `fit-window-to-buffer' steals space from the lower window if and only if the upper window is not large enough. Otherwise it steals only from the upper window. What do you expect me to do if the upper window is not large enough? I do not have a solution for this because at the time I display the buffer I don't know how large the window is supposed to be. I can (1) do the calculations of `fit-window-to-buffer' before trying to split the window and (2) not split if the window won't fit and reuse the lower window instead. But such a change is too invasive for the moment and wouldn't help anyway if the lower window is too small. You simply ask too much here :-( > I have no idea how to fix that. I'm currently struggling with a solution based on your ideas but am not yet sure whether I'll be able to come up with a fix in the next days. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Sep 2012 19:37: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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134877459316781 (code B ref 1806); Thu, 27 Sep 2012 19:37:01 +0000 Received: (at 1806) by debbugs.gnu.org; 27 Sep 2012 19:36:33 +0000 Received: from localhost ([127.0.0.1]:59270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THJsv-0004Mc-Cc for submit@debbugs.gnu.org; Thu, 27 Sep 2012 15:36:33 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:33939 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THJss-0004MU-TM for 1806@debbugs.gnu.org; Thu, 27 Sep 2012 15:36:31 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id A27FE451CCEB; Thu, 27 Sep 2012 12:36:23 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> Date: Thu, 27 Sep 2012 22:24:30 +0300 In-Reply-To: <50648DAF.5070409@gmx.at> (martin rudalics's message of "Thu, 27 Sep 2012 19:32:31 +0200") Message-ID: <87d317l15d.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> and `set-window-start' like in the previously >> used `dired-pop-to-buffer'. > > You never talked about `set-window-start' in the present context before. > `with-temp-buffer-window' goes to `point-min' in the buffer it displays > - is that not sufficient? A month ago in revno:109790 you added two lines to `dired-pop-to-buffer': ;; See Bug#12281. (set-window-start nil (point-min)) so I wondered if this is still necessary after the recent redesign of `dired-mark-pop-up' to not cause the same bug as reported in bug#12281. >> The second regression is that the value `t' >> of `window-combination-limit' is ignored, > > I don't understand again. If `window-combination-limit' is t it remains > t and is obeyed. If it's 'temp-buffer or 'temp-buffer-resize it changes > its value to t. Some time ago setting `window-combination-limit' to t allowed `fit-window-to-buffer' not to steal space from the lower window. Only resizing at the cost of the upper window was allowed because it has a common parent when `window-combination-limit' is t. Now it seems it has no effect and `fit-window-to-buffer' ignores the fact that windows were split with `window-combination-limit' is t. > `fit-window-to-buffer' steals space from the lower window if and only if > the upper window is not large enough. Otherwise it steals only from the > upper window. What do you expect me to do if the upper window is not > large enough? I do not have a solution for this because at the time I > display the buffer I don't know how large the window is supposed to be. > I can (1) do the calculations of `fit-window-to-buffer' before trying to > split the window and (2) not split if the window won't fit and reuse the > lower window instead. But such a change is too invasive for the moment > and wouldn't help anyway if the lower window is too small. The problem is that it steals space when the upper window is large and the *Marked files* buffer is large. But it can't be completely displayed anyway, so there is no need to resize the lower window. When the upper window is small to split, there is no problem - it just reuses the lower window. > You simply ask too much here :-( I'm not asking anything special. I just believe that I found a bug in `fit-window-to-buffer' and `window-combination-limit'. Some time ago `fit-window-to-buffer' obeyed the value t of `window-combination-limit', and I don't understand why it's different now. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Sep 2012 06:33: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134881394212320 (code B ref 1806); Fri, 28 Sep 2012 06:33:01 +0000 Received: (at 1806) by debbugs.gnu.org; 28 Sep 2012 06:32:22 +0000 Received: from localhost ([127.0.0.1]:59650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THU7Z-0003Ce-1v for submit@debbugs.gnu.org; Fri, 28 Sep 2012 02:32:21 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:54511) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1THU7V-0003CT-Hs for 1806@debbugs.gnu.org; Fri, 28 Sep 2012 02:32:19 -0400 Received: (qmail invoked by alias); 28 Sep 2012 06:32:08 -0000 Received: from 62-47-50-162.adsl.highway.telekom.at (EHLO [62.47.50.162]) [62.47.50.162] by mail.gmx.net (mp036) with SMTP; 28 Sep 2012 08:32:08 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+hb2lmZ+WhQ7AExUWjCOlXKbVEkplFyVRmZxQzbA 8xlsWSLhZxeJNB Message-ID: <50654463.2010008@gmx.at> Date: Fri, 28 Sep 2012 08:32:03 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> In-Reply-To: <87d317l15d.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > A month ago in revno:109790 you added two lines to `dired-pop-to-buffer': > > ;; See Bug#12281. > (set-window-start nil (point-min)) > > so I wondered if this is still necessary after the recent redesign of > `dired-mark-pop-up' to not cause the same bug as reported in bug#12281. Hopefully not. Otherwise _all_ uses of `with-output-to-temp-buffer' and `with-temp-buffer-window' - which both do (goto-char (point-min)) in the buffer to be displayed - would be faulty in this regard. > Some time ago setting `window-combination-limit' to t allowed > `fit-window-to-buffer' not to steal space from the lower window. Your memory must be wrong. At least in Emacs 24.1 I can easily shrink the lower window by fitting the midlle window to its buffer. > Only resizing at the cost of the upper window was allowed because it > has a common parent when `window-combination-limit' is t. Now it seems > it has no effect and `fit-window-to-buffer' ignores the fact that > windows were split with `window-combination-limit' is t. Setting `window-combination-limit' had and has only one effect in this regard - that resizing a window _preferably_ resizes that window's buddy first. But if this is not sufficient, any other window can get resized. Try to do some random splitting with `window-combination-limit' t and then do M-x `maximize-window' for any version starting with 24.1. > The problem is that it steals space when the upper window is large ... I suppose you mean "when the upper window is small" here ... > and the *Marked files* buffer is large. But it can't be completely > displayed anyway, so there is no need to resize the lower window. IIUC `fit-window-to-buffer' always tried to display as much as possible within limits imposed, for example, by `temp-buffer-max-height'. Can you tell me when and where it restricted itself to just some area of the frame? > I'm not asking anything special. I just believe that I found a bug in > `fit-window-to-buffer' and `window-combination-limit'. Some time ago > `fit-window-to-buffer' obeyed the value t of `window-combination-limit', > and I don't understand why it's different now. Please point me to any version where you saw that. Maybe I'm missing something. Obviously all I say here does not preclude that we inhibit resizing any other but the buddy window in `fit-window-to-buffer'. But we have to agree on such a restriction first. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Sep 2012 10:29: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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13488281275867 (code B ref 1806); Fri, 28 Sep 2012 10:29:01 +0000 Received: (at 1806) by debbugs.gnu.org; 28 Sep 2012 10:28:47 +0000 Received: from localhost ([127.0.0.1]:59818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THXoN-0001Wa-25 for submit@debbugs.gnu.org; Fri, 28 Sep 2012 06:28:47 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:35660 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THXoB-0001W5-FP for 1806@debbugs.gnu.org; Fri, 28 Sep 2012 06:28:45 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 43B46451CD3F; Fri, 28 Sep 2012 03:28:14 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> Date: Fri, 28 Sep 2012 12:38:37 +0300 In-Reply-To: <50654463.2010008@gmx.at> (martin rudalics's message of "Fri, 28 Sep 2012 08:32:03 +0200") Message-ID: <87bogqbgci.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> The problem is that it steals space when the upper window is large > > ... I suppose you mean "when the upper window is small" here ... When a window has 30 lines in height, I call it "large" :-) > IIUC `fit-window-to-buffer' always tried to display as much as possible > within limits imposed, for example, by `temp-buffer-max-height'. Can > you tell me when and where it restricted itself to just some area of the > frame? I'll try to provide the exact details: 1. When the Dired window is small (less than 7 lines in height), there is no problem because it reuses the lower window. 2. When the Dired window is large (more than 7 lines in height) and a list of marked files is small: 2.1. When `window-combination-limit' is nil, the result of `dired-mark-pop-up' is horribly ugly (when `temp-buffer-resize-mode' is enabled). But thank you `window-combination-limit' is not nil anymore, so there is no problem now. 2.2. When `window-combination-limit' is non-nil, the result is still bad looking because `fit-window-to-buffer' is missing like in the original version of `dired-pop-to-buffer'. This is a regression. 2.3. When a list of files is too large to fit into split windows, it resizes the lower window. What I misremembered is that actually it never tried to avoid resizing the lower window. Sorry for my amnesia. This is not a regression. Its result looks like when `window-combination-limit' is nil, but since a large list of files is rarely displayed in Dired, this is a minor problem. So the main problem that remains is the need to use `fit-window-to-buffer'. I see three possible variants to fix this: 1. Call `fit-window-to-buffer' directly in `dired-mark-pop-up'. 2. Call `fit-window-to-buffer' in `display-buffer-below-selected' using a new action specifier. 3. Enable `temp-buffer-resize-mode'. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Sep 2012 13:14: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134883803824157 (code B ref 1806); Fri, 28 Sep 2012 13:14:01 +0000 Received: (at 1806) by debbugs.gnu.org; 28 Sep 2012 13:13:58 +0000 Received: from localhost ([127.0.0.1]:59951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THaOB-0006HY-Mx for submit@debbugs.gnu.org; Fri, 28 Sep 2012 09:13:57 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:37820) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1THaO5-0006HM-1r for 1806@debbugs.gnu.org; Fri, 28 Sep 2012 09:13:53 -0400 Received: (qmail invoked by alias); 28 Sep 2012 13:13:37 -0000 Received: from 62-47-50-162.adsl.highway.telekom.at (EHLO [62.47.50.162]) [62.47.50.162] by mail.gmx.net (mp020) with SMTP; 28 Sep 2012 15:13:37 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18zv/M4FMkz+1yzBxQ/UAUlTiDA0Z24jDh2pVDZsv feKr+u7Af6CAKa Message-ID: <5065A2A0.1000302@gmx.at> Date: Fri, 28 Sep 2012 15:14:08 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> In-Reply-To: <87bogqbgci.fsf@mail.jurta.org> Content-Type: multipart/mixed; boundary="------------010604090305020307020907" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------010604090305020307020907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit >>> The problem is that it steals space when the upper window is large >> ... I suppose you mean "when the upper window is small" here ... > > When a window has 30 lines in height, I call it "large" :-) So splitting a 30 lines window is not enough for getting you enough space for the Marked Files buffer. How many lines would you need? >> IIUC `fit-window-to-buffer' always tried to display as much as possible >> within limits imposed, for example, by `temp-buffer-max-height'. Can >> you tell me when and where it restricted itself to just some area of the >> frame? > > I'll try to provide the exact details: > > 1. When the Dired window is small (less than 7 lines in height), > there is no problem because it reuses the lower window. Because `window--try-to-split-window' fails immediately, I presume. > 2. When the Dired window is large (more than 7 lines in height) > and a list of marked files is small: > > 2.1. When `window-combination-limit' is nil, > the result of `dired-mark-pop-up' is horribly ugly > (when `temp-buffer-resize-mode' is enabled). But thank you > `window-combination-limit' is not nil anymore, > so there is no problem now. What you probably intend to say between these lines is that users should not have to enable `temp-buffer-resize-mode' to avoid that horribly ugly result. > 2.2. When `window-combination-limit' is non-nil, the result is still > bad looking because `fit-window-to-buffer' is missing like in the > original version of `dired-pop-to-buffer'. This is a regression. This is the part I don't understand. Suppose with Emacs -Q I do C-x 2 (setq window-combination-limit t) (temp-buffer-resize-mode 1) C-x d for some directory, mark some files and type D, the space for the *Deletions* window is taken from the upper window only. > 2.3. When a list of files is too large to fit into split windows, it > resizes the lower window. What I misremembered is that actually it > never tried to avoid resizing the lower window. Sorry for my amnesia. > This is not a regression. Its result looks like when > `window-combination-limit' is nil, but since a large list of files > is rarely displayed in Dired, this is a minor problem. We agree here. > So the main problem that remains is the need to use `fit-window-to-buffer'. I suppose you intend "the need to enable `temp-buffer-resize-mode'" here. `fit-window-to-buffer' has been used all the time. > I see three possible variants to fix this: > > 1. Call `fit-window-to-buffer' directly in `dired-mark-pop-up'. This solves the problem at hand but is no general fix. In addition we'd have to maintain things like `dired-shrink-to-fit' forever. > 2. Call `fit-window-to-buffer' in `display-buffer-below-selected' > using a new action specifier. This is still not a complete solution since `fit-window-to-buffer' should apply whenever we create a new window. > 3. Enable `temp-buffer-resize-mode'. From your and Chong less than enthusiastic comments this is no good. I think your idea to pass an appropriate alist entry to `display-buffer' was best. I attach a patch which should do that, in principle (actually I just revived the respective part from my old specifiers approach). Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a corresponding entry to `display-buffer-alist' as you proposed earlier. (Someone would have to formulate that for users nicely and in the appropriate context.) The resizing request by `temp-buffer-resize-mode' is still done explicitly in the corresponding hook but this can be moved to `display-buffer' in a similar fashion. Unless we decide that `temp-buffer-resize-mode' should be removed, that is, moved to `display-buffer-alist'. martin --------------010604090305020307020907 Content-Type: text/plain; name="window-height-width.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="window-height-width.diff" === modified file 'etc/NEWS' --- etc/NEWS 2012-09-25 04:13:02 +0000 +++ etc/NEWS 2012-09-28 09:42:19 +0000 @@ -723,14 +723,11 @@ *** New macro `with-temp-buffer-window'. -*** New options `temp-buffer-resize-frames' and -`temp-buffer-resize-regexps'. - *** `temp-buffer-resize-mode' no longer resizes windows that have been reused. -*** New function `fit-frame-to-buffer' and new option -`fit-frame-to-buffer-bottom-margin'. +*** New function `fit-frame-to-buffer' and new options +`fit-frame-to-buffer' and `fit-frame-to-buffer-bottom-margin'. *** New display action functions `display-buffer-below-selected', `display-buffer-at-bottom' and `display-buffer-in-previous-window'. @@ -745,6 +742,9 @@ *** New display action alist entry `previous-window', if non-nil, specifies window to reuse in `display-buffer-in-previous-window'. +*** New display action alist entries `window-height' and `window-width' +to specify size of new window created by `display-buffer'. + *** The following variables are obsolete, as they can be replaced by appropriate entries in the `display-buffer-alist' function introduced in Emacs 24.1: === modified file 'lisp/ChangeLog' --- lisp/ChangeLog 2012-09-25 08:20:05 +0000 +++ lisp/ChangeLog 2012-09-28 09:32:16 +0000 @@ -1,3 +1,32 @@ +2012-09-28 Martin Rudalics + + * window.el (window--display-buffer): New argument ALIST. Obey + window-height and window-width alist entries. + (window--try-to-split-window): New argument ALIST. Bind + window-combination-limit to t when the window's size shall be + changed and window-combination-limit equals `window-size'. + (display-buffer-in-atom-window) + (display-buffer-in-major-side-window) + (display-buffer-in-side-window, display-buffer-same-window) + (display-buffer-reuse-window, display-buffer-pop-up-frame) + (display-buffer-pop-up-window, display-buffer-below-selected) + (display-buffer-at-bottom, display-buffer-in-previous-window) + (display-buffer-use-some-window): Adjust all callers of + window--display-buffer and window--try-to-split-window. + (fit-frame-to-buffer): New option. + (fit-window-to-buffer): Can resize frames if fit-frame-to-buffer + is non-nil. + + * help.el (temp-buffer-resize-frames) + (temp-buffer-resize-regexps): Remove options. + (temp-buffer-resize-mode): Adjust doc-string. + (resize-temp-buffer-window): Don't consult + temp-buffer-resize-regexps. Use fit-frame-to-buffer instead of + temp-buffer-resize-frames. + + * dired.el (dired-mark-pop-up): Call display-buffer-below-selected + with a fit-window-to-buffer alist entry. + 2012-09-25 Martin Rudalics * window.el (window--resize-child-windows): When resizing child === modified file 'lisp/dired.el' --- lisp/dired.el 2012-09-25 04:13:02 +0000 +++ lisp/dired.el 2012-09-28 09:03:53 +0000 @@ -2997,7 +2997,8 @@ (let ((split-height-threshold 0)) (with-temp-buffer-window buffer - (cons 'display-buffer-below-selected nil) + (cons 'display-buffer-below-selected + '((window-height . fit-window-to-buffer))) #'(lambda (window _value) (with-selected-window window (unwind-protect === modified file 'lisp/help.el' --- lisp/help.el 2012-09-22 12:56:08 +0000 +++ lisp/help.el 2012-09-28 09:03:00 +0000 @@ -981,26 +981,6 @@ :group 'help :version "24.2") -(defcustom temp-buffer-resize-frames nil - "Non-nil means `temp-buffer-resize-mode' can resize frames. -A frame can be resized if and only if its root window is a live -window. The height of the root window is subject to the values of -`temp-buffer-max-height' and `window-min-height'." - :type 'boolean - :version "24.2" - :group 'help) - -(defcustom temp-buffer-resize-regexps nil - "List of regexps that inhibit Temp Buffer Resize mode. -Any window of a buffer whose name matches one of these regular -expressions is left alone by Temp Buffer Resize mode." - :type '(repeat - :tag "Buffer" - :value "" - (regexp :format "%v")) - :version "24.3" - :group 'help) - (define-minor-mode temp-buffer-resize-mode "Toggle auto-resizing temporary buffer windows (Temp Buffer Resize Mode). With a prefix argument ARG, enable Temp Buffer Resize mode if ARG @@ -1014,9 +994,8 @@ A window is resized only if it has been specially created for the buffer. Windows that have shown another buffer before are not -resized. A window showing a buffer whose name matches any of the -expressions in `temp-buffer-resize-regexps' is not resized. A -frame is resized only if `temp-buffer-resize-frames' is non-nil. +resized. A frame is resized only if `fit-frame-to-buffer' is +non-nil. This mode is used by `help', `apropos' and `completion' buffers, and some others." @@ -1034,33 +1013,28 @@ Do not make WINDOW higher than `temp-buffer-max-height' nor smaller than `window-min-height'. Do nothing if WINDOW is not vertically combined or some of its contents are scrolled out of -view. Do nothing if the name of WINDOW's buffer matches an -expression in `temp-buffer-resize-regexps'." +view." (setq window (window-normalize-window window t)) (let ((buffer-name (buffer-name (window-buffer window)))) - (unless (catch 'found - (dolist (regexp temp-buffer-resize-regexps) - (when (string-match regexp buffer-name) - (throw 'found t)))) - (let ((height (if (functionp temp-buffer-max-height) - (with-selected-window window - (funcall temp-buffer-max-height (window-buffer))) - temp-buffer-max-height)) - (quit-cadr (cadr (window-parameter window 'quit-restore)))) - (cond - ;; Don't resize WINDOW if it showed another buffer before. - ((and (eq quit-cadr 'window) - (pos-visible-in-window-p (point-min) window) - (window-combined-p window)) - (fit-window-to-buffer window height)) - ((and temp-buffer-resize-frames - (eq quit-cadr 'frame) - (eq window (frame-root-window window))) - (let ((frame (window-frame window))) - (fit-frame-to-buffer - frame (+ (frame-height frame) - (- (window-total-size window)) - height))))))))) + (let ((height (if (functionp temp-buffer-max-height) + (with-selected-window window + (funcall temp-buffer-max-height (window-buffer))) + temp-buffer-max-height)) + (quit-cadr (cadr (window-parameter window 'quit-restore)))) + (cond + ;; Don't resize WINDOW if it showed another buffer before. + ((and (eq quit-cadr 'window) + (pos-visible-in-window-p (point-min) window) + (window-combined-p window)) + (fit-window-to-buffer window height)) + ((and fit-frame-to-buffer + (eq quit-cadr 'frame) + (eq window (frame-root-window window))) + (let ((frame (window-frame window))) + (fit-frame-to-buffer + frame (+ (frame-height frame) + (- (window-total-size window)) + height)))))))) ;;; Help windows. (defcustom help-window-select 'other === modified file 'lisp/window.el' --- lisp/window.el 2012-09-25 08:20:05 +0000 +++ lisp/window.el 2012-09-28 09:24:46 +0000 @@ -508,7 +508,7 @@ (window-make-atom (window-parent window)) ;; Display BUFFER in NEW and return NEW. (window--display-buffer - buffer new 'window display-buffer-mark-dedicated)))) + buffer new 'window alist display-buffer-mark-dedicated)))) (defun window--atom-check-1 (window) "Subroutine of `window--atom-check'." @@ -706,7 +706,7 @@ ;; does not get resized. (set-window-parameter new 'delete-window 'delete-side-window) ;; Install BUFFER in new window and return NEW. - (window--display-buffer buffer new 'window 'side)))) + (window--display-buffer buffer new 'window alist 'side)))) (defun delete-side-window (window) "Delete side window WINDOW." @@ -814,7 +814,7 @@ ;; ALIST (or, better, avoided in the "other" functions). (or (and this-window ;; Reuse `this-window'. - (window--display-buffer buffer this-window 'reuse 'side)) + (window--display-buffer buffer this-window 'reuse alist 'side)) (and (or (not max-slots) (< slots max-slots)) (or (and next-window ;; Make new window before `next-window'. @@ -839,13 +839,14 @@ window 'delete-window 'delete-side-window) window))) (set-window-parameter window 'window-slot slot) - (window--display-buffer buffer window 'window 'side)) + (window--display-buffer buffer window 'window alist 'side)) (and best-window ;; Reuse `best-window'. (progn ;; Give best-window the new slot value. (set-window-parameter best-window 'window-slot slot) - (window--display-buffer buffer best-window 'reuse 'side))))))))) + (window--display-buffer + buffer best-window 'reuse alist 'side))))))))) (defun window--side-check (&optional frame) "Check the side window configuration of FRAME. @@ -5077,7 +5078,7 @@ (with-selected-window window (split-window-below)))))))) -(defun window--try-to-split-window (window) +(defun window--try-to-split-window (window &optional alist) "Try to split WINDOW. Return value returned by `split-window-preferred-function' if it represents a live window, nil otherwise." @@ -5085,9 +5086,14 @@ (not (frame-parameter (window-frame window) 'unsplittable)) (let* ((window-combination-limit ;; When `window-combination-limit' equals - ;; `display-buffer' bind it to t so resizing steals - ;; space preferably from the window that was split. - (if (eq window-combination-limit 'display-buffer) + ;; `display-buffer' or equals `resize-window' and a + ;; `window-height' or `window-width' alist entry are + ;; present, bind it to t so resizing steals space + ;; preferably from the window that was split. + (if (or (eq window-combination-limit 'display-buffer) + (and (eq window-combination-limit 'window-size) + (or (cdr (assq 'window-height alist)) + (cdr (assq 'window-width alist))))) t window-combination-limit)) (new-window @@ -5144,7 +5150,7 @@ (/ (- (window-total-height window) (window-total-height)) 2)) (error nil)))) -(defun window--display-buffer (buffer window type &optional dedicated) +(defun window--display-buffer (buffer window type &optional alist dedicated) "Display BUFFER in WINDOW and make its frame visible. TYPE must be one of the symbols `reuse', `window' or `frame' and is passed unaltered to `display-buffer-record-window'. Set @@ -5159,6 +5165,58 @@ (set-window-dedicated-p window dedicated)) (when (memq type '(window frame)) (set-window-prev-buffers window nil))) + (let ((parameter (window-parameter window 'quit-restore)) + (height (cdr (assq 'window-height alist))) + (width (cdr (assq 'window-width alist)))) + (when (or (memq type '(window frame)) + (and (eq (car parameter) 'same) + (memq (nth 1 parameter) '(window frame)))) + ;; Adjust height of new window or frame. + (cond + ((not height)) + ((numberp height) + (let* ((new-height + (if (integerp height) + height + (round + (* (window-total-size (frame-root-window window)) + height)))) + (delta (- new-height (window-total-size window)))) + (cond + ((and (window-resizable-p window delta nil 'safe) + (window-combined-p window)) + (window-resize window delta nil 'safe)) + ((or (eq type 'frame) + (and (eq (car parameter) 'same) + (eq (nth 1 parameter) 'frame))) + (set-frame-height + (window-frame window) + (+ (frame-height (window-frame window)) delta)))))) + ((functionp height) + (ignore-errors (funcall height window)))) + ;; Adjust width of a window or frame. + (cond + ((not width)) + ((numberp width) + (let* ((new-width + (if (integerp width) + width + (round + (* (window-total-size (frame-root-window window) t) + width)))) + (delta (- new-width (window-total-size window t)))) + (cond + ((and (window-resizable-p window delta t 'safe) + (window-combined-p window t)) + (window-resize window delta t 'safe)) + ((or (eq type 'frame) + (and (eq (car parameter) 'same) + (eq (nth 1 parameter) 'frame))) + (set-frame-width + (window-frame window) + (+ (frame-width (window-frame window)) delta)))))) + ((functionp width) + (ignore-errors (funcall width window)))))) window)) (defun window--maybe-raise-frame (frame) @@ -5400,7 +5458,7 @@ (unless (or (cdr (assq 'inhibit-same-window alist)) (window-minibuffer-p) (window-dedicated-p)) - (window--display-buffer buffer (selected-window) 'reuse))) + (window--display-buffer buffer (selected-window) 'reuse alist))) (defun display-buffer--maybe-same-window (buffer alist) "Conditionally display BUFFER in the selected window. @@ -5448,7 +5506,7 @@ (get-buffer-window-list buffer 'nomini frames)))))) (when (window-live-p window) - (prog1 (window--display-buffer buffer window 'reuse) + (prog1 (window--display-buffer buffer window 'reuse alist) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame (window-frame window))))))) @@ -5485,8 +5543,8 @@ (when (and fun (setq frame (funcall fun)) (setq window (frame-selected-window frame))) - (prog1 (window--display-buffer buffer window - 'frame display-buffer-mark-dedicated) + (prog1 (window--display-buffer + buffer window 'frame alist display-buffer-mark-dedicated) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame frame)))))) @@ -5511,11 +5569,11 @@ (not (frame-parameter frame 'unsplittable)))) ;; Attempt to split largest or least recently used window. (setq window (or (window--try-to-split-window - (get-largest-window frame t)) + (get-largest-window frame t) alist) (window--try-to-split-window - (get-lru-window frame t))))) - (prog1 (window--display-buffer buffer window - 'window display-buffer-mark-dedicated) + (get-lru-window frame t) alist)))) + (prog1 (window--display-buffer + buffer window 'window alist display-buffer-mark-dedicated) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame (window-frame window))))))) @@ -5534,21 +5592,21 @@ (and pop-up-windows (display-buffer-pop-up-window buffer alist)))) -(defun display-buffer-below-selected (buffer _alist) +(defun display-buffer-below-selected (buffer alist) "Try displaying BUFFER in a window below the selected window. This either splits the selected window or reuses the window below the selected one." (let (window) (or (and (not (frame-parameter nil 'unsplittable)) - (setq window (window--try-to-split-window (selected-window))) + (setq window (window--try-to-split-window (selected-window) alist)) (window--display-buffer - buffer window 'window display-buffer-mark-dedicated)) + buffer window 'window alist display-buffer-mark-dedicated)) (and (setq window (window-in-direction 'below)) (not (window-dedicated-p window)) (window--display-buffer - buffer window 'reuse display-buffer-mark-dedicated))))) + buffer window 'reuse alist display-buffer-mark-dedicated))))) -(defun display-buffer-at-bottom (buffer _alist) +(defun display-buffer-at-bottom (buffer alist) "Try displaying BUFFER in a window at the botom of the selected frame. This either splits the window at the bottom of the frame or the frame's root window, or reuses an existing window at the bottom @@ -5556,20 +5614,20 @@ (let (bottom-window window) (walk-window-tree (lambda (window) (setq bottom-window window))) (or (and (not (frame-parameter nil 'unsplittable)) - (setq window (window--try-to-split-window bottom-window)) + (setq window (window--try-to-split-window bottom-window alist)) (window--display-buffer - buffer window 'window display-buffer-mark-dedicated)) + buffer window 'window alist display-buffer-mark-dedicated)) (and (not (frame-parameter nil 'unsplittable)) (setq window (condition-case nil (split-window (frame-root-window)) (error nil))) (window--display-buffer - buffer window 'window display-buffer-mark-dedicated)) + buffer window 'window alist display-buffer-mark-dedicated)) (and (setq window bottom-window) (not (window-dedicated-p window)) (window--display-buffer - buffer window 'reuse display-buffer-mark-dedicated))))) + buffer window 'reuse alist display-buffer-mark-dedicated))))) (defun display-buffer-in-previous-window (buffer alist) "Display BUFFER in a window previously showing it. @@ -5625,7 +5683,7 @@ (setq best-window window))) ;; Return best or second best window found. (when (setq window (or best-window second-best-window)) - (window--display-buffer buffer window 'reuse)))) + (window--display-buffer buffer window 'reuse alist)))) (defun display-buffer-use-some-window (buffer alist) "Display BUFFER in an existing window. @@ -5653,7 +5711,7 @@ (get-largest-window 0 not-this-window)))) (when (window-live-p window) (prog1 - (window--display-buffer buffer window 'reuse) + (window--display-buffer buffer window 'reuse alist) (window--even-window-heights window) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame (window-frame window))))))) @@ -5923,6 +5981,97 @@ window)))) ;;; Resizing buffers to fit their contents exactly. +(defcustom fit-frame-to-buffer nil + "Non-nil means `fit-window-to-buffer' can resize frames. +A frame can be resized if and only if its root window is a live +window. The height of the root window is subject to the values +of `fit-frame-to-buffer-max-height' and `window-min-height'." + :type 'boolean + :version "24.2" + :group 'help) + +(defcustom fit-frame-to-buffer-bottom-margin 4 + "Bottom margin for `fit-frame-to-buffer'. +This is the number of lines `fit-frame-to-buffer' leaves free at the +bottom of the display in order to not obscure the system task bar." + :type 'integer + :version "24.2" + :group 'windows) + +(defun fit-frame-to-buffer (&optional frame max-height min-height) + "Adjust height of FRAME to display its buffer's contents exactly. +FRAME can be any live frame and defaults to the selected one. + +Optional argument MAX-HEIGHT specifies the maximum height of +FRAME and defaults to the height of the display below the current +top line of FRAME minus FIT-FRAME-TO-BUFFER-BOTTOM-MARGIN. +Optional argument MIN-HEIGHT specifies the minimum height of +FRAME." + (interactive) + (setq frame (window-normalize-frame frame)) + (let* ((root (frame-root-window frame)) + (frame-min-height + (+ (- (frame-height frame) (window-total-size root)) + window-min-height)) + (frame-top (frame-parameter frame 'top)) + (top (if (consp frame-top) + (funcall (car frame-top) (cadr frame-top)) + frame-top)) + (frame-max-height + (- (/ (- (x-display-pixel-height frame) top) + (frame-char-height frame)) + fit-frame-to-buffer-bottom-margin)) + (compensate 0) + delta) + (when (and (window-live-p root) (not (window-size-fixed-p root))) + (with-selected-window root + (cond + ((not max-height) + (setq max-height frame-max-height)) + ((numberp max-height) + (setq max-height (min max-height frame-max-height))) + (t + (error "%s is an invalid maximum height" max-height))) + (cond + ((not min-height) + (setq min-height frame-min-height)) + ((numberp min-height) + (setq min-height (min min-height frame-min-height))) + (t + (error "%s is an invalid minimum height" min-height))) + ;; When tool-bar-mode is enabled and we have just created a new + ;; frame, reserve lines for toolbar resizing. This is needed + ;; because for reasons unknown to me Emacs (1) reserves one line + ;; for the toolbar when making the initial frame and toolbars + ;; are enabled, and (2) later adds the remaining lines needed. + ;; Our code runs IN BETWEEN (1) and (2). YMMV when you're on a + ;; system that behaves differently. + (let ((quit-restore (window-parameter root 'quit-restore)) + (lines (tool-bar-lines-needed frame))) + (when (and quit-restore (eq (car quit-restore) 'frame) + (not (zerop lines))) + (setq compensate (1- lines)))) + (message "%s" compensate) + (setq delta + ;; Always count a final newline - we don't do any + ;; post-processing, so let's play safe. + (+ (count-screen-lines nil nil t) + (- (window-body-size)) + compensate))) + ;; Move away from final newline. + (when (and (eobp) (bolp) (not (bobp))) + (set-window-point root (line-beginning-position 0))) + (set-window-start root (point-min)) + (set-window-vscroll root 0) + (condition-case nil + (set-frame-height + frame + (min (max (+ (frame-height frame) delta) + min-height) + max-height)) + (error (setq delta nil)))) + delta)) + (defun fit-window-to-buffer (&optional window max-height min-height) "Adjust height of WINDOW to display its buffer's contents exactly. WINDOW must be a live window and defaults to the selected one. @@ -5943,9 +6092,12 @@ WINDOW was scrolled." (interactive) (setq window (window-normalize-window window t)) - ;; Can't resize a full height or fixed-size window. - (unless (or (window-size-fixed-p window) - (window-full-height-p window)) + (cond + ((window-size-fixed-p window)) + ((window-full-height-p window) + (when fit-frame-to-buffer + (fit-frame-to-buffer (window-frame window)))) + (t (with-selected-window window (let* ((height (window-total-size)) (min-height @@ -5961,7 +6113,7 @@ ;; Can't get larger than height of frame. (min max-height (window-total-size (frame-root-window window))) - ;, Don't delete other windows. + ;; Don't delete other windows. (+ height (window-max-delta nil nil window)))) ;; Make `desired-height' the height necessary to show ;; all of WINDOW's buffer, constrained by MIN-HEIGHT @@ -6024,89 +6176,7 @@ (window-resize window 1 nil window) (setq desired-height (1+ desired-height))))) (error (setq delta nil))) - delta)))) - -(defcustom fit-frame-to-buffer-bottom-margin 4 - "Bottom margin for `fit-frame-to-buffer'. -This is the number of lines `fit-frame-to-buffer' leaves free at the -bottom of the display in order to not obscure the system task bar." - :type 'integer - :version "24.2" - :group 'windows) - -(defun fit-frame-to-buffer (&optional frame max-height min-height) - "Adjust height of FRAME to display its buffer's contents exactly. -FRAME can be any live frame and defaults to the selected one. - -Optional argument MAX-HEIGHT specifies the maximum height of -FRAME and defaults to the height of the display below the current -top line of FRAME minus FIT-FRAME-TO-BUFFER-BOTTOM-MARGIN. -Optional argument MIN-HEIGHT specifies the minimum height of -FRAME." - (interactive) - (setq frame (window-normalize-frame frame)) - (let* ((root (frame-root-window frame)) - (frame-min-height - (+ (- (frame-height frame) (window-total-size root)) - window-min-height)) - (frame-top (frame-parameter frame 'top)) - (top (if (consp frame-top) - (funcall (car frame-top) (cadr frame-top)) - frame-top)) - (frame-max-height - (- (/ (- (x-display-pixel-height frame) top) - (frame-char-height frame)) - fit-frame-to-buffer-bottom-margin)) - (compensate 0) - delta) - (when (and (window-live-p root) (not (window-size-fixed-p root))) - (with-selected-window root - (cond - ((not max-height) - (setq max-height frame-max-height)) - ((numberp max-height) - (setq max-height (min max-height frame-max-height))) - (t - (error "%s is an invalid maximum height" max-height))) - (cond - ((not min-height) - (setq min-height frame-min-height)) - ((numberp min-height) - (setq min-height (min min-height frame-min-height))) - (t - (error "%s is an invalid minimum height" min-height))) - ;; When tool-bar-mode is enabled and we have just created a new - ;; frame, reserve lines for toolbar resizing. This is needed - ;; because for reasons unknown to me Emacs (1) reserves one line - ;; for the toolbar when making the initial frame and toolbars - ;; are enabled, and (2) later adds the remaining lines needed. - ;; Our code runs IN BETWEEN (1) and (2). YMMV when you're on a - ;; system that behaves differently. - (let ((quit-restore (window-parameter root 'quit-restore)) - (lines (tool-bar-lines-needed frame))) - (when (and quit-restore (eq (car quit-restore) 'frame) - (not (zerop lines))) - (setq compensate (1- lines)))) - (message "%s" compensate) - (setq delta - ;; Always count a final newline - we don't do any - ;; post-processing, so let's play safe. - (+ (count-screen-lines nil nil t) - (- (window-body-size)) - compensate))) - ;; Move away from final newline. - (when (and (eobp) (bolp) (not (bobp))) - (set-window-point root (line-beginning-position 0))) - (set-window-start root (point-min)) - (set-window-vscroll root 0) - (condition-case nil - (set-frame-height - frame - (min (max (+ (frame-height frame) delta) - min-height) - max-height)) - (error (setq delta nil)))) - delta)) + delta))))) (defun window-safely-shrinkable-p (&optional window) "Return t if WINDOW can be shrunk without shrinking other windows. === modified file 'src/ChangeLog' --- src/ChangeLog 2012-09-25 07:01:52 +0000 +++ src/ChangeLog 2012-09-28 09:10:58 +0000 @@ -1,3 +1,8 @@ +2012-09-28 Martin Rudalics + + * window.c (Vwindow_combination_limit): New default value. + (Qwindow_size): New symbol replacing Qtemp_buffer_resize. + 2012-09-25 Eli Zaretskii * character.c (char_string, string_char): Remove calls to === modified file 'src/window.c' --- src/window.c 2012-09-23 08:44:20 +0000 +++ src/window.c 2012-09-28 08:57:02 +0000 @@ -60,7 +60,7 @@ static Lisp_Object Qreplace_buffer_in_windows, Qget_mru_window; static Lisp_Object Qwindow_resize_root_window, Qwindow_resize_root_window_vertically; static Lisp_Object Qscroll_up, Qscroll_down, Qscroll_command; -static Lisp_Object Qsafe, Qabove, Qbelow, Qtemp_buffer_resize, Qclone_of; +static Lisp_Object Qsafe, Qabove, Qbelow, Qwindow_size, Qclone_of; static int displayed_window_lines (struct window *); static int count_windows (struct window *); @@ -6704,7 +6704,7 @@ DEFSYM (Qreplace_buffer_in_windows, "replace-buffer-in-windows"); DEFSYM (Qrecord_window_buffer, "record-window-buffer"); DEFSYM (Qget_mru_window, "get-mru-window"); - DEFSYM (Qtemp_buffer_resize, "temp-buffer-resize"); + DEFSYM (Qwindow_size, "window-size"); DEFSYM (Qtemp_buffer_show_hook, "temp-buffer-show-hook"); DEFSYM (Qabove, "above"); DEFSYM (Qbelow, "below"); @@ -6807,16 +6807,16 @@ window has no parent window or the window shall become a combination orthogonal to the one it is part of. -`temp-buffer-resize' means that splitting a window for displaying a - temporary buffer makes a new parent window provided - `temp-buffer-resize-mode' is enabled. Otherwise, this value is - handled like nil. +`window-size' means that splitting a window for displaying a buffer + makes a new parent window provided `display-buffer' is supposed to + explicitly the window's size due to the presence of a + `window-height' or `window-width' entry in the alist used by + `display-buffer'. Otherwise, this value is handled like nil. `temp-buffer' means that splitting a window for displaying a temporary buffer always makes a new parent window. Otherwise, this value is handled like nil. - `display-buffer' means that splitting a window for displaying a buffer always makes a new parent window. Since temporary buffers are displayed by the function `display-buffer', this value is stronger @@ -6829,7 +6829,7 @@ sibling. Other values are reserved for future use. */); - Vwindow_combination_limit = Qtemp_buffer_resize; + Vwindow_combination_limit = Qwindow_size; DEFVAR_LISP ("window-persistent-parameters", Vwindow_persistent_parameters, doc: /* Alist of persistent window parameters. --------------010604090305020307020907-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Sep 2012 15:42: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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13488468685449 (code B ref 1806); Fri, 28 Sep 2012 15:42:01 +0000 Received: (at 1806) by debbugs.gnu.org; 28 Sep 2012 15:41:08 +0000 Received: from localhost ([127.0.0.1]:60660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THcge-0001Pq-IF for submit@debbugs.gnu.org; Fri, 28 Sep 2012 11:41:08 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:42764 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1THcgc-0001Pj-GO for 1806@debbugs.gnu.org; Fri, 28 Sep 2012 11:41:07 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 822FB451CCA1; Fri, 28 Sep 2012 08:40:54 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> Date: Fri, 28 Sep 2012 18:27:21 +0300 In-Reply-To: <5065A2A0.1000302@gmx.at> (martin rudalics's message of "Fri, 28 Sep 2012 15:14:08 +0200") Message-ID: <87k3ve5fs6.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I attach a patch which should do that, in principle (actually > I just revived the respective part from my old specifiers approach). Thank you! I'm starting to test your patch, and I see no problems, everything works fine, it fixes all regressions in Dired. > Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a > corresponding entry to `display-buffer-alist' as you proposed earlier. This means that `dired-shrink-to-fit' could be marked obsolete? > (Someone would have to formulate that for users nicely and in the > appropriate context.) This text could be written to the CURRENT-NAME arg of `make-obsolete'. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Sep 2012 10:49:02 +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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13490020951414 (code B ref 1806); Sun, 30 Sep 2012 10:49:02 +0000 Received: (at 1806) by debbugs.gnu.org; 30 Sep 2012 10:48:15 +0000 Received: from localhost ([127.0.0.1]:34076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIH4I-0000Ml-Ho for submit@debbugs.gnu.org; Sun, 30 Sep 2012 06:48:14 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:52868) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TIH4F-0000Md-LP for 1806@debbugs.gnu.org; Sun, 30 Sep 2012 06:48:12 -0400 Received: (qmail invoked by alias); 30 Sep 2012 10:47:50 -0000 Received: from 62-47-62-159.adsl.highway.telekom.at (EHLO [62.47.62.159]) [62.47.62.159] by mail.gmx.net (mp004) with SMTP; 30 Sep 2012 12:47:50 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+WA/EZrUuWO2XDzcB1mdAMN0sYcc3adRK3DxVVIF 8T9tYTYWjA3Tvz Message-ID: <5068234C.1020600@gmx.at> Date: Sun, 30 Sep 2012 12:47:40 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> In-Reply-To: <87k3ve5fs6.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.3 (/) >> I attach a patch which should do that, in principle (actually >> I just revived the respective part from my old specifiers approach). > > Thank you! I'm starting to test your patch, and I see no problems, > everything works fine, it fixes all regressions in Dired. Installed. >> Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a >> corresponding entry to `display-buffer-alist' as you proposed earlier. > > This means that `dired-shrink-to-fit' could be marked obsolete? I think so. >> (Someone would have to formulate that for users nicely and in the >> appropriate context.) > > This text could be written to the CURRENT-NAME arg of `make-obsolete'. Do we support multiline strings in `make-obsolete'? martin From unknown Mon Jun 23 13:12:18 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Juri Linkov Subject: bug#1806: closed (Re: dired-pop-to-buffer in wrong place) Message-ID: References: <877grbk4se.fsf@mail.jurta.org> <87r63gzcap.fsf@jurta.org> X-Gnu-PR-Message: they-closed 1806 X-Gnu-PR-Package: emacs Reply-To: 1806@debbugs.gnu.org Date: Sun, 30 Sep 2012 13:43:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1349012583-19926-1" This is a multi-part message in MIME format... ------------=_1349012583-19926-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #1806: dired-pop-to-buffer in wrong place which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 1806@debbugs.gnu.org. --=20 1806: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D1806 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1349012583-19926-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 1806-done) by debbugs.gnu.org; 30 Sep 2012 13:42:29 +0000 Received: from localhost ([127.0.0.1]:34153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIJmt-0005AY-Vx for submit@debbugs.gnu.org; Sun, 30 Sep 2012 09:42:29 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:39882 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TIJmq-0005AQ-RM for 1806-done@debbugs.gnu.org; Sun, 30 Sep 2012 09:42:26 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 49ADA451CB5B; Sun, 30 Sep 2012 06:42:02 -0700 (PDT) From: Juri Linkov To: martin rudalics Subject: Re: dired-pop-to-buffer in wrong place Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> Date: Sun, 30 Sep 2012 16:40:17 +0300 In-Reply-To: <5068234C.1020600@gmx.at> (martin rudalics's message of "Sun, 30 Sep 2012 12:47:40 +0200") Message-ID: <877grbk4se.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 1806-done Cc: 1806-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Installed. Thanks, I'm happily marking bug#1806 as done :-) > Do we support multiline strings in `make-obsolete'? I believe both `make-obsolete' (that could be used for `dired-pop-to-buffer') and `make-obsolete-variable' (for `dired-shrink-to-fit') support multiline strings. ------------=_1349012583-19926-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 15:31:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n06FVFoS020582 for ; Tue, 6 Jan 2009 07:31:16 -0800 Received: from mx10.gnu.org ([199.232.76.166]:44002) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKDsa-0004TZ-DK for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:30:04 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKDte-0001eT-Vv for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:31:14 -0500 Received: from relay03.kiev.sovam.com ([62.64.120.201]:53363) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKDte-0001e9-KR for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 10:31:10 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKDtc-000Crn-AT for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:31:08 +0200 From: Juri Linkov To: emacs-pretest-bug@gnu.org Subject: dired-pop-to-buffer in wrong place Organization: JURTA Date: Tue, 06 Jan 2009 17:29:55 +0200 Message-ID: <87r63gzcap.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 233cb89e4cdd9c68f6fe52a505261b56 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6665 [Jan 06 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: Genre and OS details not recognized. After 2008-12-11 change to window.el and dired.el that fixed the bug #1488, I have difficulties using dired. Before this change, running a dired operation on many files displayed a pop-up window *below* the dired buffer and immediately *above* the minibuffer. This is the most convenient place to display a list of file names, because it is near the minibuffer where the user types more input for the command (a shell command or a directory to copy files to). But now this list of files is displayed somewhere else - on the top of the side window. Thus now this list is as far for minibuffer as possible. This is because `dired-pop-to-buffer' doesn't call `split-window' anymore that used to split windows vertically even on a wide-screen display. This is the same problem as I reported in http://thread.gmane.org/gmane.emacs.devel/93011/focus=94236 i.e. we need a special option to split windows vertically where necessary. -- Juri Linkov http://www.jurta.org/emacs/ ------------=_1349012583-19926-1-- From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 00:13:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134930956111982 (code B ref 1806); Thu, 04 Oct 2012 00:13:02 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 00:12:41 +0000 Received: from localhost ([127.0.0.1]:51948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZ3Q-000378-E6 for submit@debbugs.gnu.org; Wed, 03 Oct 2012 20:12:41 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:34814 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJZ3N-00036y-Hj for 1806@debbugs.gnu.org; Wed, 03 Oct 2012 20:12:38 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id EDB7C451CCBF; Wed, 3 Oct 2012 17:12:33 -0700 (PDT) From: Juri Linkov Organization: JURTA 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> Date: Thu, 04 Oct 2012 02:29:57 +0300 In-Reply-To: <5068234C.1020600@gmx.at> (martin rudalics's message of "Sun, 30 Sep 2012 12:47:40 +0200") Message-ID: <87y5jnqmma.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >>> Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a >>> corresponding entry to `display-buffer-alist' as you proposed earlier. >> >> This means that `dired-shrink-to-fit' could be marked obsolete? > > I think so. > >>> (Someone would have to formulate that for users nicely and in the >>> appropriate context.) Do you think this is a good formulation: === modified file 'lisp/dired.el' --- lisp/dired.el 2012-09-30 12:11:18 +0000 +++ lisp/dired.el 2012-10-03 23:28:07 +0000 @@ -248,6 +248,10 @@ (defvar dired-shrink-to-fit t ;; I see no reason ever to make this nil -- rms. ;; (> baud-rate search-slow-speed) "Non-nil means Dired shrinks the display buffer to fit the marked files.") +(make-obsolete-variable 'dired-shrink-to-fit + "use the Customization interface to add a new rule +to `display-buffer-alist' where condition regexp is \"Marked Files\", +action argument symbol is `window-height' and its value is nil." "24.3") (defvar dired-file-version-alist) @@ -2940,6 +2943,7 @@ (defun dired-mark-prompt (arg files) (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." + (declare (obsolete dired-mark-pop-up "24.3")) (let ((split-window-preferred-function (lambda (window) (or (and (let ((split-height-threshold 0)) @@ -2981,6 +2985,11 @@ (defun dired-mark-pop-up (buffer-or-name window is not shown if there is just one file, `dired-no-confirm' is t, or OP-SYMBOL is a member of the list in `dired-no-confirm'. +By default Dired shrinks the display buffer to fit the marked files. +To disable this, use the Customization interface to add a new rule +to `display-buffer-alist' where condition regexp is \"Marked Files\", +action argument symbol is `window-height' and its value is nil. + FILES is the list of marked files. It can also be (t FILENAME) in the case of one marked file, to distinguish that from using just the current file. PS: Also I noticed that there are no new actions in the Customization interface for `display-buffer-alist'. I guess you omitted the action `display-buffer-at-bottom' because it's not yet ready for prime time. But is there a reason to not add `display-buffer-below-selected' to `display-buffer--action-function-custom-type'? From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 03:56:02 +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: To: "'Juri Linkov'" , "'martin rudalics'" Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13493229421366 (code B ref 1806); Thu, 04 Oct 2012 03:56:02 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 03:55:42 +0000 Received: from localhost ([127.0.0.1]:52102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJcXF-0000Lz-IN for submit@debbugs.gnu.org; Wed, 03 Oct 2012 23:55:41 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47255) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJcXD-0000Ln-QQ for 1806@debbugs.gnu.org; Wed, 03 Oct 2012 23:55:40 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q943tTcg031437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 03:55:30 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q943tSFP026048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 03:55:29 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q943tScx028823; Wed, 3 Oct 2012 22:55:28 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2012 20:55:27 -0700 From: "Drew Adams" 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><8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at><87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at><87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at><87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at><87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at><87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at><87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> Date: Wed, 3 Oct 2012 20:55:25 -0700 Message-ID: <6DB676587CBE4A41853D0F5832C04D72@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87y5jnqmma.fsf@mail.jurta.org> Thread-Index: Ac2hxQlIeQRhdDU+T9CDytjsP0WyjgAHjWAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > + (declare (obsolete dired-mark-pop-up "24.3")) Huh? Are you kidding? I certainly hope so. We just spent a long time fixing bug #7533 - it took two years to get it fixed right. `dired-mark-pop-up' now works as it should. Please do not even think about deprecating `dired-mark-pop-up'. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 07:46: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134933670821471 (code B ref 1806); Thu, 04 Oct 2012 07:46:01 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 07:45:08 +0000 Received: from localhost ([127.0.0.1]:52245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJg7I-0005aG-1v for submit@debbugs.gnu.org; Thu, 04 Oct 2012 03:45:08 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:41001) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TJg7E-0005ZV-Kz for 1806@debbugs.gnu.org; Thu, 04 Oct 2012 03:45:06 -0400 Received: (qmail invoked by alias); 04 Oct 2012 07:44:54 -0000 Received: from 62-47-48-227.adsl.highway.telekom.at (EHLO [62.47.48.227]) [62.47.48.227] by mail.gmx.net (mp010) with SMTP; 04 Oct 2012 09:44:54 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+9pftMTfm9PVL6juRUuFL4iZJxzrECDJIbYnWr5H gQirKYT/uSl+i2 Message-ID: <506D3E75.4090403@gmx.at> Date: Thu, 04 Oct 2012 09:44:53 +0200 From: martin rudalics MIME-Version: 1.0 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> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> In-Reply-To: <87y5jnqmma.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > Do you think this is a good formulation: > > === modified file 'lisp/dired.el' > --- lisp/dired.el 2012-09-30 12:11:18 +0000 > +++ lisp/dired.el 2012-10-03 23:28:07 +0000 > @@ -248,6 +248,10 @@ (defvar dired-shrink-to-fit t > ;; I see no reason ever to make this nil -- rms. > ;; (> baud-rate search-slow-speed) > "Non-nil means Dired shrinks the display buffer to fit the marked files.") > +(make-obsolete-variable 'dired-shrink-to-fit > + "use the Customization interface to add a new rule > +to `display-buffer-alist' where condition regexp is \"Marked Files\", > +action argument symbol is `window-height' and its value is nil." "24.3") I think it's OK. Though we should decide generally whether we (1) want an exact match for such buffers (that is, including space and asterisks) and (2) whether obsoletion strings can be that long (I have not found any when I searched recently). > (defvar dired-file-version-alist) > > @@ -2940,6 +2943,7 @@ (defun dired-mark-prompt (arg files) > > (defun dired-pop-to-buffer (buf) > "Pop up buffer BUF in a way suitable for Dired." > + (declare (obsolete dired-mark-pop-up "24.3")) > (let ((split-window-preferred-function > (lambda (window) > (or (and (let ((split-height-threshold 0)) > @@ -2981,6 +2985,11 @@ (defun dired-mark-pop-up (buffer-or-name > window is not shown if there is just one file, `dired-no-confirm' > is t, or OP-SYMBOL is a member of the list in `dired-no-confirm'. > > +By default Dired shrinks the display buffer to fit the marked files. > +To disable this, use the Customization interface to add a new rule > +to `display-buffer-alist' where condition regexp is \"Marked Files\", > +action argument symbol is `window-height' and its value is nil. > + > FILES is the list of marked files. It can also be (t FILENAME) > in the case of one marked file, to distinguish that from using > just the current file. We should add the detailed code somewhere, probably to the Elisp manual. As an example, I didn't know that using an ACTION argument where the FUNCTION component is nil would work in the first place. > PS: Also I noticed that there are no new actions in the Customization > interface for `display-buffer-alist'. I guess you omitted the action > `display-buffer-at-bottom' because it's not yet ready for prime time. > But is there a reason to not add `display-buffer-below-selected' to > `display-buffer--action-function-custom-type'? No. I didn't recall that option any more (although I must have done so earlier because I added `display-buffer-in-previous-window' to it). There are further issues. (1) Document alist entries like `window-height' and `window-width' somehwere without blowing up the doc-string of `display-buffer'. (2) Decide whether and how we can use `window-height' and `window-width' to replace `split-height-threshold' and `split-width-threshold'. Or maybe find some other substitute. (3) Include alist entries to specify a minimum height/width for a window to reuse (there's a request for such a feature in a bug report). (4) As soon as we switch to pixel sizes allow to specify all these options in terms of pixels too. (5) Handle the delayed evaluation of `fit-window-to-buffer' in `vc-diff-finish' somehow. Currently, we can't pass this to `display-buffer' because we don't know the final size of the buffer when we call it. So this means that we have to find out whether `display-buffer' would have called `fit-window-to-buffer' in the first place and, if so, call `fit-window-to-buffer' when we know the final buffer size. Tedious to do. (6) Related: Move `display-buffer-mark-dedicated' to the alists. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 07:46:02 +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: To: Drew Adams Cc: 'Juri Linkov' , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134933671521487 (code B ref 1806); Thu, 04 Oct 2012 07:46:02 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 07:45:15 +0000 Received: from localhost ([127.0.0.1]:52248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJg7O-0005aW-IA for submit@debbugs.gnu.org; Thu, 04 Oct 2012 03:45:15 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:44254) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TJg7L-0005a9-B1 for 1806@debbugs.gnu.org; Thu, 04 Oct 2012 03:45:12 -0400 Received: (qmail invoked by alias); 04 Oct 2012 07:45:01 -0000 Received: from 62-47-48-227.adsl.highway.telekom.at (EHLO [62.47.48.227]) [62.47.48.227] by mail.gmx.net (mp028) with SMTP; 04 Oct 2012 09:45:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18ubbUTQCIuweMddnMC0HSRSC0GXNaF7Be3l0KHoU eoxRv+houTsvtz Message-ID: <506D3E7D.80809@gmx.at> Date: Thu, 04 Oct 2012 09:45:01 +0200 From: martin rudalics MIME-Version: 1.0 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><8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at><87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at><87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at><87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at><87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at><87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at><87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> <6DB676587CBE4A41853D0F5832C04D72@us.oracle.com> In-Reply-To: <6DB676587CBE4A41853D0F5832C04D72@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> + (declare (obsolete dired-mark-pop-up "24.3")) > > Huh? Are you kidding? I certainly hope so. > > We just spent a long time fixing bug #7533 - it took two years to get it fixed > right. `dired-mark-pop-up' now works as it should. > > Please do not even think about deprecating `dired-mark-pop-up'. Don't worry. This is a `declare' form for `dired-pop-to-buffer' telling people to use `dired-mark-pop-up' instead. martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 08:56:02 +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: To: martin rudalics Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134934094327571 (code B ref 1806); Thu, 04 Oct 2012 08:56:02 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 08:55:43 +0000 Received: from localhost ([127.0.0.1]:52315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJhDa-0007Ad-Le for submit@debbugs.gnu.org; Thu, 04 Oct 2012 04:55:43 -0400 Received: from ps18281.dreamhost.com ([69.163.218.105]:42910 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJhDX-0007AV-QD for 1806@debbugs.gnu.org; Thu, 04 Oct 2012 04:55:41 -0400 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 24149451CCFC; Thu, 4 Oct 2012 01:55:33 -0700 (PDT) From: Juri Linkov Organization: JURTA References: <87r63gzcap.fsf@jurta.org> <87y5k1lhn6.fsf@mail.jurta.org> <505ED4BB.3030103@gmx.at> <87txunj0ej.fsf@mail.jurta.org> <50602A8D.6010203@gmx.at> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> <506D3E75.4090403@gmx.at> Date: Thu, 04 Oct 2012 11:51:11 +0300 In-Reply-To: <506D3E75.4090403@gmx.at> (martin rudalics's message of "Thu, 04 Oct 2012 09:44:53 +0200") Message-ID: <87pq4yaadc.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> +(make-obsolete-variable 'dired-shrink-to-fit >> + "use the Customization interface to add a new rule >> +to `display-buffer-alist' where condition regexp is \"Marked Files\", >> +action argument symbol is `window-height' and its value is nil." "24.3") > > I think it's OK. Though we should decide generally whether we (1) want > an exact match for such buffers (that is, including space and asterisks) In the Customization UI it would be simple to type a regexp without special characters. OTOH, the user will be able to copy the exact match from the docstring, so we could add the exact match to docstrings: (make-obsolete-variable 'dired-shrink-to-fit "use the Customization interface to add a new rule to `display-buffer-alist' where condition regexp is \"^ \\*Marked Files\\*$\", action argument symbol is `window-height' and its value is nil." "24.3") > and (2) whether obsoletion strings can be that long (I have not found > any when I searched recently). Just try to evaluate this `make-obsolete-variable' and see its result in `C-h v dired-shrink-to-fit RET'. > We should add the detailed code somewhere, probably to the Elisp manual. > As an example, I didn't know that using an ACTION argument where the > FUNCTION component is nil would work in the first place. I learned about this feature from Stefan's comment in http://debbugs.gnu.org/3419#133 > There are further issues. Let's discuss them on emacs-devel. From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 13:18: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: To: Juri Linkov Cc: 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134935665121273 (code B ref 1806); Thu, 04 Oct 2012 13:18:01 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 13:17:31 +0000 Received: from localhost ([127.0.0.1]:52593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJlIw-0005X2-5u for submit@debbugs.gnu.org; Thu, 04 Oct 2012 09:17:31 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:56042) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TJlIs-0005Wn-0e for 1806@debbugs.gnu.org; Thu, 04 Oct 2012 09:17:27 -0400 Received: (qmail invoked by alias); 04 Oct 2012 13:17:14 -0000 Received: from 62-47-48-227.adsl.highway.telekom.at (EHLO [62.47.48.227]) [62.47.48.227] by mail.gmx.net (mp028) with SMTP; 04 Oct 2012 15:17:14 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX198s0BwgXt8fxmTd701MH9LDhxZJzFEQF0mN8c0xd hDs3ihAu9+QEyt Message-ID: <506D8C73.70507@gmx.at> Date: Thu, 04 Oct 2012 15:17:39 +0200 From: martin rudalics MIME-Version: 1.0 References: <87r63gzcap.fsf@jurta.org> <87y5k1lhn6.fsf@mail.jurta.org> <505ED4BB.3030103@gmx.at> <87txunj0ej.fsf@mail.jurta.org> <50602A8D.6010203@gmx.at> <8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at> <87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at> <87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at> <87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at> <87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at> <87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at> <87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> <506D3E75.4090403@gmx.at> <87pq4yaadc.fsf@mail.jurta.org> In-Reply-To: <87pq4yaadc.fsf@mail.jurta.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > In the Customization UI it would be simple to type a regexp without > special characters. OTOH, the user will be able to copy the exact match > from the docstring, so we could add the exact match to docstrings: > > (make-obsolete-variable 'dired-shrink-to-fit > "use the Customization interface to add a new rule > to `display-buffer-alist' where condition regexp is \"^ \\*Marked Files\\*$\", > action argument symbol is `window-height' and its value is nil." "24.3") Good. >> and (2) whether obsoletion strings can be that long (I have not found >> any when I searched recently). > > Just try to evaluate this `make-obsolete-variable' and see its result > in `C-h v dired-shrink-to-fit RET'. You're right. So please install them. >> We should add the detailed code somewhere, probably to the Elisp manual. >> As an example, I didn't know that using an ACTION argument where the >> FUNCTION component is nil would work in the first place. > > I learned about this feature from Stefan's comment in > http://debbugs.gnu.org/3419#133 I see. BTW, this bug must have been swept under my carpet. Though the "reuse window & resize it" part should have been fixed by now. I'll close it ;-) >> There are further issues. > > Let's discuss them on emacs-devel. OK Thanks, martin From unknown Mon Jun 23 13:12:18 2025 X-Loop: help-debbugs@gnu.org Subject: bug#1806: dired-pop-to-buffer in wrong place Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Oct 2012 14:05:02 +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: To: "'martin rudalics'" Cc: 'Juri Linkov' , 1806@debbugs.gnu.org Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134935948726738 (code B ref 1806); Thu, 04 Oct 2012 14:05:02 +0000 Received: (at 1806) by debbugs.gnu.org; 4 Oct 2012 14:04:47 +0000 Received: from localhost ([127.0.0.1]:54076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJm2g-0006xD-Ac for submit@debbugs.gnu.org; Thu, 04 Oct 2012 10:04:46 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:27145) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TJm2e-0006x1-6n for 1806@debbugs.gnu.org; Thu, 04 Oct 2012 10:04:44 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q94E4TLN017012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Oct 2012 14:04:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q94E4R9Z019018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2012 14:04:28 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q94E4RSo026252; Thu, 4 Oct 2012 09:04:27 -0500 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Oct 2012 07:04:26 -0700 From: "Drew Adams" 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><8739261q8h.fsf@mail.jurta.org> <5061807D.1010401@gmx.at><87pq59z3nr.fsf@mail.jurta.org> <5062C173.3050402@gmx.at><87r4ppxfgm.fsf@mail.jurta.org> <5062E0FA.50701@gmx.at><87sja3rj1p.fsf@mail.jurta.org> <50648DAF.5070409@gmx.at><87d317l15d.fsf@mail.jurta.org> <50654463.2010008@gmx.at><87bogqbgci.fsf@mail.jurta.org> <5065A2A0.1000302@gmx.at><87k3ve5fs6.fsf@mail.jurta.org> <5068234C.1020600@gmx.at> <87y5jnqmma.fsf@mail.jurta.org> <6DB676587CBE4A41853D0F5832C04D72@us.oracle.com> <506D3E7D.80809@gmx.at> Date: Thu, 4 Oct 2012 07:04:22 -0700 Message-ID: <9C1B8829655D4639900E2727BFC0495D@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <506D3E7D.80809@gmx.at> Thread-Index: Ac2iBCxGkmjRi2qEQ1+a78KW9Oxo+AANJtEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -6.3 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > Don't worry. This is a `declare' form for > `dired-pop-to-buffer' telling > people to use `dired-mark-pop-up' instead. Very sorry. I wondered why it was together with the `dired-pop-to-buffer' defun. I didn't understand and jumped to a wrong conclusion. Thanks, and again, sorry.