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: Fri, 28 Sep 2012 08:32:03 +0200 Message-ID: <50654463.2010008@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> <50648DAF.5070409@gmx.at> <87d317l15d.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 1348813982 844 80.91.229.3 (28 Sep 2012 06:33:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 06:33:02 +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 Fri Sep 28 08:33:08 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 1THU8I-0002Om-8R for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2012 08:33:06 +0200 Original-Received: from localhost ([::1]:54139 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THU8D-0002zr-47 for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2012 02:33:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THU87-0002rX-U6 for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 02:32:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THU86-00059Y-Pj for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 02:32:55 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THU86-00059T-LY for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 02:32:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1THU8D-0003De-Vu for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2012 02:33:02 -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: 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: Original-Received: via spool by 1806-submit@debbugs.gnu.org id=B1806.134881394212320 (code B ref 1806); Fri, 28 Sep 2012 06:33:01 +0000 Original-Received: (at 1806) by debbugs.gnu.org; 28 Sep 2012 06:32:22 +0000 Original-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 Original-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 Original-Received: (qmail invoked by alias); 28 Sep 2012 06:32:08 -0000 Original-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 In-Reply-To: <87d317l15d.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:64971 Archived-At: > 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