From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Mon, 02 Jul 2012 17:33:03 +0400 Message-ID: <4FF1A30F.4090806@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> 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 1341236000 3712 80.91.229.3 (2 Jul 2012 13:33:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2012 13:33:20 +0000 (UTC) Cc: 11810@debbugs.gnu.org, emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 02 15:33:19 2012 Return-path: Envelope-to: ged-emacs-devel@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 1Slgkg-0004N4-89 for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 15:33:18 +0200 Original-Received: from localhost ([::1]:34172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slgkf-0001nb-2K for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 09:33:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slgkc-0001n9-9o for emacs-devel@gnu.org; Mon, 02 Jul 2012 09:33:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlgkV-0003wI-JS for emacs-devel@gnu.org; Mon, 02 Jul 2012 09:33:13 -0400 Original-Received: from forward12.mail.yandex.net ([95.108.130.94]:51774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlgkV-0003vC-0n for emacs-devel@gnu.org; Mon, 02 Jul 2012 09:33:07 -0400 Original-Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward12.mail.yandex.net (Yandex) with ESMTP id 9D5F9C21637; Mon, 2 Jul 2012 17:33:03 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341235983; bh=aO7bIUoTrTNctfppwuafl5w6S8vGYM5PtynvbifcR70=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gYVfy89HHmCkC4fLEDqV/CmsxlJJL9M6AxwEpnRLcK6629HqHJqGTMGN4icOQHTuj 2LbbjvTbT7WDXJQQQDY7qSvkKGQ7AD6cxepz8s1ZkeQt+ZGj4KIXSXEx+y237E2f2k 4LmTPDRuWDMAB1ZIRUbj9NdEnmLntncx3nPuZqCM= Original-Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id 6843B16A04AF; Mon, 2 Jul 2012 17:33:03 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id X2O8YSoN-X2O8uuXo; Mon, 2 Jul 2012 17:33:03 +0400 X-Yandex-Rcpt-Suid: rudalics@gmx.at X-Yandex-Rcpt-Suid: emacs-devel@gnu.org X-Yandex-Rcpt-Suid: 11810@debbugs.gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341235983; bh=aO7bIUoTrTNctfppwuafl5w6S8vGYM5PtynvbifcR70=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TkG4uhlBilv3wLmOvThecx0ToEIkrjZEF1T3a0pj8ZpAl+ywxYEJyojiM/CJx7jj9 gbu2w2vODzuLmByGl/N2vE5qXgQB0ok0wyVGF6Tjj986RhEdrk0TA1DsZGp8XMrdRF D2G9V3VUfJlWxswUdgW2JXcuTF83eFeSIO9dbCAU= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4FF146F4.1080103@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 95.108.130.94 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151349 Archived-At: On 02.07.2012 11:00, martin rudalics wrote: > > From what I understand in `window-combination-resize' docstring, its > > value decides whether splitting a window borrows space only from > > adjacent window, or from all windows in a "combination" (so they all get > > resized). For that to happen, a window splitting should occur, right? > > But when we're displaying a buffer in pre-existing window, no splitting > > occurs, just resizing. > > And `even-window-heights' controls whether it should be resized at all. > > IIUC, the case we're talking about is that of a split frame where one > window gets reused. Now, with `window-combination-resize' non-nil, > `display-buffer' practically always makes a new window in such a case > because it can steal space from both existing windows. Quitting or > deleting the new window will restore the sizes of the original windows > regardless of whether `temp-buffer-resize-mode' has been used or not. I see. Still, I'm primarily interested in the scenario where the windows don't get split (with appropriate split-*-threshold values), and in this case `even-window-heights' value has effect. Note that if the widow does get split, `vc-diff' behaves okay, because `q' deletes the used window, and the configuration becomes as it was (at least with `window-combination-resize' nil). > >> We could simply remove the `temp-buffer-resize-mode' check in > >> `quit-window'. I hardly understand what implications this might have. > > > > I think it's just trying to making sure that (nth 3 quad) is of the > > right type, so that the comparison doesn't blow up. > > No (at least not as far as I originally conceived it). My idea was as > follows: > > (1) When `temp-buffer-resize-mode' is non-nil and the window size has > changed, chances are that the change was caused by > `temp-buffer-resize-mode' so it seems pretty safe to rescind that > change. I don't think so. Like I said, the value saved in 'quit-restore parameter is the same in this case, whether `temp-buffer-resize-mode' is on or not. So even if `temp-buffer-resize-mode' is on, we can't confidently decide that the value was set by it. > (2) When `temp-buffer-resize-mode' is nil and the window size has > changed, the change was probably due to some manual intervention > probably needed to see more of a buffer originally present and it > seems better to leave that change alone. > > But maybe my conception was flawed. Would it be harder to *not set* the 'quit-restore parameter in cases when we don't want the configuration restored, instead? But as it is, I'm not sure what's the problem with always using its value when present. I've been running Emacs with the tiny patch I posted for a couple of days, and it seems fine. Could you describe the scenario with "seeing more of a buffer originally present"? > > If I enable temp-buffer-resize-mode before doing vc-diff, after I quit > > the window, its size does get restored. > > It should be sufficient to set the variable `temp-buffer-resize-mode' > locally in that buffer. Yes, but that's not what I meant. > > Also, (nth 3 quad) is integer at that point even temp-buffer-resize-mode > > is disabled, so the mode check doesn't make sense. > > To be safe, though, we could replace it with `integerp' call. > > Yes, but the `condition-case' should handle any problems with it. Don't we want to execute the code following (when resize ...) either way? > In any case, we have to cater for the case where people (I'm not sure > whether I got Andreas right) want to disable adjusting the window in the > first place. So I really think we should simply special-case this by > providing some option like `vc-fit-diff-window-to-buffer' and adjust the > window only if that variable has a non-nil value. If it's non-nil, we > can either I'm fine with either behavior (not resizing or properly restoring), but `vc-diff' is not the only culprit. `vc-log-print' also does the shrinking, although it's harder to observe. If there will be a variable, I don't see why it should be local to VC. Are there users who would want windows shrunk by VC, but not other packages, or vice versa? > (1) set `temp-buffer-resize-mode' locally in such buffers, or > > (2) provide yet another variable which, when set, causes `quit-window' > to re-resize the window (we could misuse `even-window-heights' for > this purpose), or That won't do if the original windows sizes were not even, like in the SO question linked to previously. > (3) re-resize the window as in your patch. -- Dmitry