From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Tue, 03 Jul 2012 22:56:14 +0400 Message-ID: <4FF3404E.6000207@yandex.ru> 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> <4FF3207B.1050609@gmx.at> 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 1341341796 16142 80.91.229.3 (3 Jul 2012 18:56:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2012 18:56:36 +0000 (UTC) Cc: 11810@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 20:56:35 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 1Sm8H1-00011H-An for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 20:56:31 +0200 Original-Received: from localhost ([::1]:45908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm8H0-0001mx-Cv for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2012 14:56:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm8Gt-0001jk-BG for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 14:56:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sm8Gq-00044P-2Z for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 14:56:22 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sm8Gp-00044I-PY for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 14:56:19 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sm8LN-0001UU-QC for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2012 15:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jul 2012 19:01:01 +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.13413420615726 (code B ref 11810); Tue, 03 Jul 2012 19:01:01 +0000 Original-Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 19:01:01 +0000 Original-Received: from localhost ([127.0.0.1]:45823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm8LM-0001UG-Jd for submit@debbugs.gnu.org; Tue, 03 Jul 2012 15:01:01 -0400 Original-Received: from forward20.mail.yandex.net ([95.108.253.145]:52719) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm8LI-0001U6-KQ for 11810@debbugs.gnu.org; Tue, 03 Jul 2012 15:00:59 -0400 Original-Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward20.mail.yandex.net (Yandex) with ESMTP id 720FF1041BEB; Tue, 3 Jul 2012 22:56:12 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341341772; bh=43PNMwWvHKfNJs1XAYdcjAiBES3M5QbeE4Eq7fOcIHA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jUzSAfLuQyvPZoTb8dsFVEw7HycGZ4taJg1za9PZZhWLEjRhhe4283bYA+f+8i9Hp Z924JLfJehHvz8pKqRqT/M2b/8NJQ4RqVuh89VoFK0/4//jWbb/JJa9qZNoNYmJKIg n6tGHZAl95BaQcbHymeLawPLu2kJns7Am8Ji9Ot0= Original-Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 49FBB1900121; Tue, 3 Jul 2012 22:56:12 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id uB4aWICb-uB4ONj1a; Tue, 3 Jul 2012 22:56:11 +0400 X-Yandex-Rcpt-Suid: rudalics@gmx.at X-Yandex-Rcpt-Suid: 11810@debbugs.gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341341772; bh=43PNMwWvHKfNJs1XAYdcjAiBES3M5QbeE4Eq7fOcIHA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mGqaG5qOvBoMlmJj9L0LwfH+1Lrmvzpz327nWhiNfqVLNi+VZ+qDT9rgg1OdX4P9Y 9WWPrnIVBrVoiGPK0kwA0RJHPbajUKyunihzRoTLE33PwbJXZMVUDM+bpFYOe4ZdXj G9Nsm5U5TpHjahDHNuFd3nQUbOd2izyPrvrnpHrQ= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4FF3207B.1050609@gmx.at> 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:61545 Archived-At: On 03.07.2012 20:40, martin rudalics wrote: > > 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. This will re-introduce the issue, the one you said `temp-buffer-resize-mode' check was guarding from. Namely, if I run `vc-diff', it reuses some window that has a neighbor vertically, I drag its window border to resize, then go back to the window and press 'q', it will restore the original height, like you said it shouldn't. > > `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'. I agree. > >> 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. Well, yes. I think that's the hard part - deciding on the set of functions and if we need to do the check with `called-interactively-p' in some of them. > >> `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. Then yes, both of them, I guess. `enlarge-window' and `enlarge-window-horizontally' could be another candidates. Not sure about `delete-window' (when we're deleting one window in a configuration), could be either way. > > 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. There are cases when we don't want it to be triggered, right? (See example at the top of this email). And when `temp-buffer-resize-mode' is t locally or globally, re-resizing code will always be triggered. Hence, the `temp-buffer-resize-mode' check in `quit-window' does not really serve the purpose you ascribe to it. Or doesn't serve it well enough. So I think the first thing to do is replace that check with (integerp ...), like I suggested, and consider the question of when not to restore window height a separate issue (maybe file a separate bug, maybe not), because the issue is already there when `temp-buffer-resize-mode' is on. > 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. Maybe so. I think this is also a separate issue, but it's closely related to identifying the set of functions after which we don't restore window sizes, because just as we might want not to restore the height after `adjust-window-trailing-edge' was called, or `shrink-buffer-if-...' was called interactively, we similarly might want to resize the windows *only* when one of those functions is called (and only when interactively, in `shrink-buffer-if...' case). > >> > 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, Yes, hence the quotes around "temp buffer". > 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. It wouldn't, because `temp-buffer-resize-mode' is off by default. Or even if it were on by default, just because it could be switched on and off, the logic there can't depend on it. > Another way is to explicitly call `resize-temp-buffer-window' and set > `temp-buffer-resize-mode' t in that buffer. I think that's the only way that restoring `vc-diff' window height could have worked with current `quit-window' code. But like I said above (see the top of this email), it fixes one problem by introducing another.