From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#1806: dired-pop-to-buffer in wrong place Date: Thu, 27 Sep 2012 19:32:31 +0200 Message-ID: <50648DAF.5070409@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> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348767196 7178 80.91.229.3 (27 Sep 2012 17:33:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Sep 2012 17:33:16 +0000 (UTC) Cc: 1806@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 27 19:33:20 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1THHxa-0001bu-Ph for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2012 19:33:15 +0200 Original-Received: from localhost ([::1]:33851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THHxT-00076V-RQ for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Sep 2012 13:33:07 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THHxO-000762-42 for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 13:33:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THHxJ-0007wF-HS for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 13:33:01 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THHxJ-0007wA-E9 for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 13:32:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1THHxN-0001V0-Uo for bug-gnu-emacs@gnu.org; Thu, 27 Sep 2012 13:33:01 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.13487671315660 (code B ref 1806); Thu, 27 Sep 2012 17:33:01 +0000 Original-Received: (at 1806) by debbugs.gnu.org; 27 Sep 2012 17:32:11 +0000 Original-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 Original-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 Original-Received: (qmail invoked by alias); 27 Sep 2012 17:32:02 -0000 Original-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 In-Reply-To: <87sja3rj1p.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64957 Archived-At: > 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