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: Wed, 04 Jul 2012 11:18:36 +0200 Message-ID: <4FF40A6C.2050601@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> <4FF3207B.1050609@gmx.at> <4FF3404E.6000207@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 1341393577 12258 80.91.229.3 (4 Jul 2012 09:19:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2012 09:19:37 +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 Wed Jul 04 11:19:37 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 1SmLkC-0005XG-PB for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2012 11:19:33 +0200 Original-Received: from localhost ([::1]:55868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmLkB-0000Qg-Ki for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2012 05:19:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmLk4-000086-Ko for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 05:19:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmLjx-0001Nf-8J for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 05:19:24 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmLjx-0001NT-4Q for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 05:19:17 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SmLoY-0005EE-P5 for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 05:24: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: Wed, 04 Jul 2012 09:24: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.134139379820031 (code B ref 11810); Wed, 04 Jul 2012 09:24:02 +0000 Original-Received: (at 11810) by debbugs.gnu.org; 4 Jul 2012 09:23:18 +0000 Original-Received: from localhost ([127.0.0.1]:47195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmLnq-0005D1-AE for submit@debbugs.gnu.org; Wed, 04 Jul 2012 05:23:18 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:45593) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SmLno-0005Ct-2e for 11810@debbugs.gnu.org; Wed, 04 Jul 2012 05:23:17 -0400 Original-Received: (qmail invoked by alias); 04 Jul 2012 09:18:28 -0000 Original-Received: from 62-47-38-82.adsl.highway.telekom.at (EHLO [62.47.38.82]) [62.47.38.82] by mail.gmx.net (mp010) with SMTP; 04 Jul 2012 11:18:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18E8bE2k/AEeZX5qgRS+mzHvQZkqTWzteppURxJtf B9yr5VbO8Wm6Px In-Reply-To: <4FF3404E.6000207@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:61563 Archived-At: > > 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, ... but only for vc-diff buffers ... > like you said > it shouldn't. ... do that for arbitrary buffers. If we remove the corresponding check in `quit-window', all windows that can be quit are affected. >> `even-window-heights' is customizable so it's not a primary issue. But >> we could undo the evening in `quit-window'. > > I agree. We'll do so when we apply your last patch ;-) >> 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. It's tedious and I wouldn't like to do it. > Then yes, both of them, I guess. > `enlarge-window' and `enlarge-window-horizontally' could be another > candidates. Yes. > Not sure about `delete-window' (when we're deleting one > window in a configuration), could be either way. No (we'd have to care about its clients like `quit-window' too then). > 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. My implicit assumption was that people using `temp-buffer-resize-mode' want automatic changes like that in vc-diff rescinded when done with the buffer. > 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. Because vc-diff does something special here. > 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. OK, let's do that. People had enough time to express their concerns about it. If problems come up, we'll hear about them soon enough. >> 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). `vc-diff' unconditionally resizes the window. What if someone simply doesn't want its `shrink-window-if-larger-than-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. That's what I meant: In that case there would not have been any resizing unless triggered by `even-window-heights'. > 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. We could make the value at the time the window was reused prevail via the quit-restore parameter: That is, save the total size of the window only if either `even-window-heights' or `temp-buffer-resize-mode' are on. >> 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. ... in a limited way, though. Let's close this thread as follows: Remove the `temp-buffer-resize-mode' check in `quit-window' and add an integerp check for the third element. If this has any bad consequences, we can still (1) have `vc-diff' use something similar to `with-output-to-temp-buffer' so that `temp-buffer-resize-mode' is honored, (2) resize the window only if `temp-buffer-resize-mode' is enabled, or (3) resize the window unconditionally as now but locally set the variable `temp-buffer-resize-mode' to t in the diff buffer. All these approaches would re-resize the window on quitting provided `even-window-heights' is nil. Independently from that we can provide an extra vc-prefixed variable which controls whether the diff window shall be resiized in the first place. As you said, that would be a different bug. More generally, we could provide an option specifying a function or regexp for all buffers whose windows should be fit to them and have `fit-window-to-buffer' (unless called interactively) honor that. That option would then override `temp-buffer-resize-mode' as well. martin