From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Mon, 02 Jul 2012 09:00:04 +0200 Message-ID: <4FF146F4.1080103@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> 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 1341212410 8708 80.91.229.3 (2 Jul 2012 07:00:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2012 07:00:10 +0000 (UTC) Cc: emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 02 09:00:10 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 1SlacD-0002Wn-1B for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 09:00:09 +0200 Original-Received: from localhost ([::1]:40808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slac8-0005bK-Q3 for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 03:00:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Slac5-0005Zq-Fc for emacs-devel@gnu.org; Mon, 02 Jul 2012 03:00:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Slac3-0007Rz-IM for emacs-devel@gnu.org; Mon, 02 Jul 2012 03:00:01 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:54696) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Slac3-0007Rg-8r for emacs-devel@gnu.org; Mon, 02 Jul 2012 02:59:59 -0400 Original-Received: (qmail invoked by alias); 02 Jul 2012 06:59:57 -0000 Original-Received: from 62-47-50-61.adsl.highway.telekom.at (EHLO [62.47.50.61]) [62.47.50.61] by mail.gmx.net (mp024) with SMTP; 02 Jul 2012 08:59:57 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19q2llacFlqftsK5VHUEJfhtMMcpAazVEmPh0Ufjc WOmChIE+GZKtek In-Reply-To: <4FF05DC0.4080609@yandex.ru> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:151345 Archived-At: > I don't understand what "implicitly" means here. Will > `even-window-heights' be nil by default? My description was sloppy and inaccurate. > 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. >> 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. (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. > 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. > 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. 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 (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 (3) re-resize the window as in your patch. WDYT? martin