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#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Tue, 03 Jul 2012 18:40:27 +0200 Message-ID: <4FF3207B.1050609@gmx.at> References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> <4FEF8935.9010508@yandex.ru> <4FF012FE.1010502@gmx.at> <4FF05DC0.4080609@yandex.ru> <4FF146F4.1080103@gmx.at> <4FF1A30F.4090806@yandex.ru> <4FF1CD2C.5000704@gmx.at> <4FF206F5.4030101@yandex.ru> <4FF29BE7.2030006@gmx.at> <4FF2EA0D.9030006@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341333694 14085 80.91.229.3 (3 Jul 2012 16:41:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2012 16:41:34 +0000 (UTC) Cc: 11810@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 18:41:32 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 1Sm6AN-0001ZN-PX for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 18:41:32 +0200 Original-Received: from localhost ([::1]:33999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm6AM-0006Nw-OH for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 12:41:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm6AK-0006NP-DO for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 12:41:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sm6AD-0008Mq-W4 for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 12:41:27 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm6AD-0008Mc-S5 for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 12:41:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sm6El-0004Ku-4Q for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 12:46:03 -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: Tue, 03 Jul 2012 16:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11810 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11810-submit@debbugs.gnu.org id=B11810.134133392116617 (code B ref 11810); Tue, 03 Jul 2012 16:46:02 +0000 Original-Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 16:45:21 +0000 Original-Received: from localhost ([127.0.0.1]:45476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm6E4-0004Jx-Kq for submit@debbugs.gnu.org; Tue, 03 Jul 2012 12:45:21 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:38553) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sm6Dz-0004Jb-8W for 11810@debbugs.gnu.org; Tue, 03 Jul 2012 12:45:16 -0400 Original-Received: (qmail invoked by alias); 03 Jul 2012 16:40:32 -0000 Original-Received: from 62-47-56-5.adsl.highway.telekom.at (EHLO [62.47.56.5]) [62.47.56.5] by mail.gmx.net (mp038) with SMTP; 03 Jul 2012 18:40:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19IhMQWXyJImKt+AwOYeJIXs4/OjQbieD7Zxs1HCK iFvyKxQxt4/62R In-Reply-To: <4FF2EA0D.9030006@yandex.ru> 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:61531 Archived-At: >> > That depends on the definition of "the user". In our case, *I* didn't >> > explicitly resize the window, `vc-diff' did. >> >> Because of `even-window-heights'? That's something I obviously forgot > > Because of `shrink-window-if-larger-than-buffer'. Sure. But as I proposed earlier we could have handled this by setting `temp-buffer-resize-mode' to t in the diff-buffer. > `even-window-heights' could have contributed in another case, if my > windows were not of equal height already. `even-window-heights' is customizable so it's not a primary issue. But we could undo the evening in `quit-window'. >> to handle when quitting a window. Maybe the best solution is to set the >> 3rd element of the quit-restore parameter iff either >> >> (1) `temp-buffer-resize-mode' is non-nil, or > > Maybe just when `fit-window-to-buffer' is called? That would account for > `shrink-window-if-larger-than-buffer', too. Unless it's an interactive call of `shrink-window-if-larger-than-buffer' probably. >> `adjust-window-trailing-edge' would be an obvious candidate. But which >> window's parameter would you clear? Both? > > What's the second one? Please keep in mind that I don't know the > window.el codebase, I'm just reading the code along the discussion. `adjust-window-trailing-edge' drags an edge between two windows and usually resizes the two windows adjacent to the edge, for example, when mouse-dragging the mode-line. Hence we have two candidates for clearing a quit-restore parameter's size element. > If `temp-buffer-resize-mode' were on, that wouldn't have made a > difference, would it? > You'd have to locally set `temp-buffer-resize-mode' to nil in all cases > when you don't want the window size to be restored afterwards, which is > the same amount of work as clearing 'quit-window parameter. Why? I set the buffer-local value only when `temp-buffer-resize-mode' is off. When it's on I don't assign a buffer-local value. The re-resize code in `quit-window' would trigger when either the local or the global value is t. Anyway, this would only handle the re-resizing when quitting the vc-diff buffer. It would not handle the case where people don't want any resizing. Maybe vc-diff should shrink iff `temp-buffer-resize-mode' is on. >> > Would a window that displayed a normal buffer previously but which now >> > is displaying a temporary buffer be considered a "window of >> > non-temporary buffer"? >> >> Only after it displays the normal buffer again. Why did you ask? > > Because that's what at issue here. I think the main two cases of > automatic shrinking are: > 1) "temp buffer" in a window that was created for it, > 2) "temp buffer" in a reused window, > and 2) is the reason I filed this bug. Remember that the vc-diff buffer is not a temporary buffer. Currently, in order to trigger automatic resizing of temporary buffer windows you have to use `with-output-to-temp-buffer'. If vc-diff had used that macro, the entire resizing issue would have been handled already. Another way is to explicitly call `resize-temp-buffer-window' and set `temp-buffer-resize-mode' t in that buffer. martin