From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#1806: dired-pop-to-buffer in wrong place Date: Fri, 16 Oct 2009 12:38:43 +0300 Organization: JURTA Message-ID: <87bpk74nsk.fsf@mail.jurta.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> Reply-To: Juri Linkov , 1806@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1255691384 11776 80.91.229.12 (16 Oct 2009 11:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2009 11:09:44 +0000 (UTC) Cc: 1806@emacsbugs.donarmstrong.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 16 13:09:33 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mykec-00041t-TR for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Oct 2009 13:07:27 +0200 Original-Received: from localhost ([127.0.0.1]:47475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mykec-0007aY-44 for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Oct 2009 07:07:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MykeW-0007Yn-8b for bug-gnu-emacs@gnu.org; Fri, 16 Oct 2009 07:07:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MykeQ-0007Wk-CF for bug-gnu-emacs@gnu.org; Fri, 16 Oct 2009 07:07:18 -0400 Original-Received: from [199.232.76.173] (port=33918 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MykeQ-0007Wh-96 for bug-gnu-emacs@gnu.org; Fri, 16 Oct 2009 07:07:14 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42994) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MykeP-0005Uc-LS for bug-gnu-emacs@gnu.org; Fri, 16 Oct 2009 07:07:13 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9GB7B4F001381; Fri, 16 Oct 2009 04:07:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9GB055l031577; Fri, 16 Oct 2009 04:00:05 -0700 Resent-Date: Fri, 16 Oct 2009 04:00:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Juri Linkov Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 16 Oct 2009 11:00:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1806 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1806-submit@emacsbugs.donarmstrong.com id=B1806.125569038030586 (code B ref 1806); Fri, 16 Oct 2009 11:00:04 +0000 Original-Received: (at 1806) by emacsbugs.donarmstrong.com; 16 Oct 2009 10:53:00 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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) In-Reply-To: <4AD81B1C.6040203@gmx.at> (martin rudalics's message of "Fri, 16 Oct 2009 09:05:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Fri, 16 Oct 2009 07:07:18 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32001 Archived-At: >> 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/