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: Wed, 04 Jul 2012 20:12:57 +0400 Message-ID: <4FF46B89.5040301@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> <4FF3404E.6000207@yandex.ru> <4FF40A6C.2050601@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 1341418423 19965 80.91.229.3 (4 Jul 2012 16:13:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2012 16:13:43 +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 Wed Jul 04 18:13:39 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 1SmSCj-0001ky-Iy for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2012 18:13:25 +0200 Original-Received: from localhost ([::1]:40835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmSCi-0000ZR-Ej for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2012 12:13:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmSCe-0000Yz-Io for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 12:13:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmSCZ-00037G-Cp for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 12:13:20 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmSCZ-000379-4A for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 12:13:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SmSHC-00086I-7A for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2012 12:18:02 -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: Wed, 04 Jul 2012 16:18: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.134141866931118 (code B ref 11810); Wed, 04 Jul 2012 16:18:02 +0000 Original-Received: (at 11810) by debbugs.gnu.org; 4 Jul 2012 16:17:49 +0000 Original-Received: from localhost ([127.0.0.1]:48183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmSGy-00085r-K6 for submit@debbugs.gnu.org; Wed, 04 Jul 2012 12:17:49 -0400 Original-Received: from forward19.mail.yandex.net ([95.108.253.144]:37891) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmSGv-00085i-05 for 11810@debbugs.gnu.org; Wed, 04 Jul 2012 12:17:47 -0400 Original-Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward19.mail.yandex.net (Yandex) with ESMTP id F36361121306; Wed, 4 Jul 2012 20:12:55 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341418376; bh=mp4DGeZfVHtpSKgnkBr60Y0jkE5arn+uT5rS7CCJTuc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BytuWEBUtCNTXQuRpUbG0fepFc9BI4t5U4S+rayUSXimtFNFY1HSBswr5ZMs+3rzF bi9uD8S+rE83/u48bV3bAGYHIZVeD6CffejPGaNgGiRlDHU3Lo8dNFjRW3mbpbGW5A N5OmkEtK8gq2X1QoX5+s4K1oKuM06noq22OCLF9Y= Original-Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id D110B6A04C9; Wed, 4 Jul 2012 20:12:55 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Ctg42i7X-Ctgqfmgl; Wed, 4 Jul 2012 20:12:55 +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=1341418375; bh=mp4DGeZfVHtpSKgnkBr60Y0jkE5arn+uT5rS7CCJTuc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ie0HkECsUTPCo3gPCmynMOml5L9qqkmRrrV5HsGgzQgruk0Z+5R9gdyzzUxPfM3/H IcXMREyc9nZb1poLvwfn1AUbPZq2gZjtMNG5eXwqxkCsslmvCHlrmMY8hi5DANYZY4 W9EAEWPypOEb1kQlDhrTYLFV68TOzVpr3Jz1hzZU= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4FF40A6C.2050601@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:61571 Archived-At: On 04.07.2012 13:18, martin rudalics wrote: > > > 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. I think it's good if all windows of this kind behave similarly. > >> `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 ;-) I tried it with just my patch applied, and it didn't work, because in this case the stored height value was of already resized window: `display-buffer-record-window' is called from `window--display-buffer', and `display-buffer-use-some-window' calls `window--even-window-heights' before `window--display-buffer'. Maybe that's fine, I'll just set the variable to nil. > >> 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. No problem, let's wait and see if/when someone complains. Until then, the issue is somewhat alleviated by the fact that you can press 'z' or 'C-x k' instead of 'q', and both of these won't trigger height restoration. > >> 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'? The idea was to disable resizing at a lower level. For example, let's call the new variable `dont-resize'. If it's set to t, then `window--resize-this-window' won't do anything. You'd rebind `dont-resize' to nil locally in select cases: in `adjust-window-trailing-edge', when `shrink-buffer-if-...' is called interactively, etc. That's the rough outline. If someone wants `shrink-window-if-...' to have no effect only in `vc-diff', well, that's a different goal. > >> 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'. I see. > > 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. I think it's a little backwards: if a user doesn't enable `temp-buffer-resize-mode' or `even-window-heights', then they probably care about keeping their window configuration the same over time. If some command like `vc-diff' still can resize a window automatically, we should strive to keep that action undo-able. There's a positive side to that suggestion (if the user sets up the preferred configuration after the temp buffer is displayed), but that doesn't outweigh the drawback. > 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. Agreed. > 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 Both 1 and 2 would be fine, I think, although 1 would require some extra work to make it work asynchronously. IIUC, `with-output-to-temp-buffer' waits until the called process completes, and `vc-diff' supports both synchronous and asynchronous execution. > (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. -- Dmitry