From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 28 15:27:19 2012 Received: (at submit) by debbugs.gnu.org; 28 Jun 2012 19:27:19 +0000 Received: from localhost ([127.0.0.1]:35725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkKN5-0003cB-8R for submit@debbugs.gnu.org; Thu, 28 Jun 2012 15:27:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41659) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkKN1-0003c2-TX for submit@debbugs.gnu.org; Thu, 28 Jun 2012 15:27:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SkKIu-00034P-Lu for submit@debbugs.gnu.org; Thu, 28 Jun 2012 15:23:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:43828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkKIu-00034J-DS for submit@debbugs.gnu.org; Thu, 28 Jun 2012 15:23:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkKIs-0000C1-Mh for bug-gnu-emacs@gnu.org; Thu, 28 Jun 2012 15:22:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SkKIq-00033L-Cj for bug-gnu-emacs@gnu.org; Thu, 28 Jun 2012 15:22:58 -0400 Received: from forward2.mail.yandex.net ([77.88.46.7]:37895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkKIp-00032o-Ot for bug-gnu-emacs@gnu.org; Thu, 28 Jun 2012 15:22:56 -0400 Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward2.mail.yandex.net (Yandex) with ESMTP id F40CF12A1F04 for ; Thu, 28 Jun 2012 23:22:52 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340911373; bh=lMU70F3pvOUqNNoglFXaUCnuGLQse/Ubz6dbp62vDg0=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=E3AQ1567RSh2vnt7a4bkYjKbsltyGepOnGNGQQYZOiy+k3Suz6nYzlzajYOdeakUJ 1jHVAM+49iDo7i2kakVkmHN+0di0z4lKthvAM99VkKxVYryNh4Pbn92dDIvXH9rzfp xYL4oFEi/VironPQ5Z3cPrRlIikQb6/Q6Lje3bMM= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id E1ADE5C0179 for ; Thu, 28 Jun 2012 23:22:52 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id MqFWVZqt-MqF8Z9lU; Thu, 28 Jun 2012 23:22:52 +0400 X-Yandex-Rcpt-Suid: bug-gnu-emacs@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340911372; bh=lMU70F3pvOUqNNoglFXaUCnuGLQse/Ubz6dbp62vDg0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type; b=NUhHizJnThmarD5PxdBN22lf8e1a4CcS1jJvUwpfWpJFQ/b1Ab3lokirUxcPvfsX4 jWc7KfFZcATKZPisAxaDi8ZPK37WlJvOjNQp8PTYpLffQ4OlBdtPRlupbLfeSGHa0L pCjgzXhOncqnM8uB7HA1yQ8tGQJyBZPmcNwkUVHs= Message-ID: <4FECAF0F.1080307@yandex.ru> Date: Thu, 28 Jun 2012 23:22:55 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.1.50; `vc-diff' shrinks pre-existing window Content-Type: multipart/mixed; boundary="------------030306060609060107090405" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) This is a multi-part message in MIME format. --------------030306060609060107090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Steps to reproduce: 1) Have a frame with such width and height that when there are 4 equal windows inside it, a `pop-to-window' invocation reuses an existing window. 2) Start with just 1 window, do C-x 3, then C-x 2 in both resulting windows. 3) Open a VC-backed file in one of the windows, make a tiny change, save, do `vc-diff'. Diff will open in one of the existing windows, and it will be shrunk to the height of the buffer. 4) Quit the diff buffer with `q'. See that the window height stays shrunk. In a similar scenario, open a file from a repository with tiny history (1 commit or so), do `vc-print-log', observe the same behavior. Thankfully, this is a much more rare occurrence. Simple patch attached. Commands messing up existing window configuration is one of my top Emacs annoyances, and AFAIK it confuses the new users, too. Maybe nil check for (window-prev-buffers) should be instead included in `shrink-window-if-larger-than-buffer', with a way to override it? --------------030306060609060107090405 Content-Type: text/plain; charset=windows-1251; name="0001-vc.el-vc-diff-finish-vc-log-internal-common-Never-sh.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-vc.el-vc-diff-finish-vc-log-internal-common-Never-sh.pa"; filename*1="tch" >From e1f5971c81fabac74280f798802b7958a44db08c Mon Sep 17 00:00:00 2001 From: Dmitry Gutov Date: Thu, 28 Jun 2012 23:18:41 +0400 Subject: [PATCH] * vc.el (vc-diff-finish, vc-log-internal-common): Never shrink pre-existing windows --- lisp/vc/vc.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 87e4e1c..697b212 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -1531,7 +1531,7 @@ to override the value of `vc-diff-switches' and `diff-switches'." (message "%s" (cdr messages)))) (diff-setup-whitespace) (goto-char (point-min)) - (when window + (when (and window (not (window-prev-buffers))) (shrink-window-if-larger-than-buffer window))) (when (and messages (not emptyp)) (message "%sdone" (car messages)))))) @@ -2147,7 +2147,8 @@ Not all VC backends support short logs!") (vc-exec-after `(let ((inhibit-read-only t)) (funcall ',setup-buttons-func ',backend ',files ',retval) - (shrink-window-if-larger-than-buffer) + (unless (window-prev-buffers) + (shrink-window-if-larger-than-buffer)) (funcall ',goto-location-func ',backend) (setq vc-sentinel-movepoint (point)) (set-buffer-modified-p nil))))) -- 1.7.10.msysgit.1 --------------030306060609060107090405-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 28 18:36:24 2012 Received: (at 11810) by debbugs.gnu.org; 28 Jun 2012 22:36:24 +0000 Received: from localhost ([127.0.0.1]:35934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkNK4-0007qN-HQ for submit@debbugs.gnu.org; Thu, 28 Jun 2012 18:36:24 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:51622) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkNK2-0007qF-Sy for 11810@debbugs.gnu.org; Thu, 28 Jun 2012 18:36:24 -0400 Received: from frontend4.mail.m-online.net (unknown [192.168.8.183]) by mail-out.m-online.net (Postfix) with ESMTP id 3WNbMn1c0vz3hhZg; Fri, 29 Jun 2012 00:32:20 +0200 (CEST) Received: from linux.local (ppp-88-217-113-177.dynamic.mnet-online.de [88.217.113.177]) by mail.mnet-online.de (Postfix) with ESMTPA id 3WNbMW2Sjtzbbfr; Fri, 29 Jun 2012 00:32:07 +0200 (CEST) Received: by linux.local (Postfix, from userid 501) id 39BF91E5603; Fri, 29 Jun 2012 00:32:10 +0200 (CEST) From: Andreas Schwab To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> X-Yow: Hey, I LIKE that POINT!! Date: Fri, 29 Jun 2012 00:32:10 +0200 In-Reply-To: <4FECAF0F.1080307@yandex.ru> (Dmitry Gutov's message of "Thu, 28 Jun 2012 23:22:55 +0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Dmitry Gutov writes: > Commands messing up existing window configuration is one of my top > Emacs annoyances, and AFAIK it confuses the new users, too. > Maybe nil check for (window-prev-buffers) should be instead included in > `shrink-window-if-larger-than-buffer', with a way to override it? I think there should at least be an option to eliminate it completely. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 28 18:49:52 2012 Received: (at 11810) by debbugs.gnu.org; 28 Jun 2012 22:49:53 +0000 Received: from localhost ([127.0.0.1]:35952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkNX6-0008CB-8Z for submit@debbugs.gnu.org; Thu, 28 Jun 2012 18:49:52 -0400 Received: from forward15.mail.yandex.net ([95.108.130.119]:39829) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkNX2-0008C2-Rz for 11810@debbugs.gnu.org; Thu, 28 Jun 2012 18:49:50 -0400 Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward15.mail.yandex.net (Yandex) with ESMTP id 32D529E157E; Fri, 29 Jun 2012 02:45:33 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340923533; bh=bsG17q3o9ztOv0pkUom+yKsXJ7c/kxxHcTEyvIurayA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UCvy0Mlv28CyO1FbisQiNynEbRDUSxXENxKe7EZXpdP3WD2sKEYPpGuBcslT0l/nn cOQg2MmDmnpkC/byQzhl3eo0Sijfa3WDkedYq0exUaaE9jpcpuYkVLO0sZE2MCg2E6 g5hOgJthW5/C5I8dbHJ5s6P5HtB6zsrMdedLza0c= Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 1162BE40408; Fri, 29 Jun 2012 02:45:33 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jW9i2Daw-jW9ud4fl; Fri, 29 Jun 2012 02:45:32 +0400 X-Yandex-Rcpt-Suid: schwab@linux-m68k.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=1340923533; bh=bsG17q3o9ztOv0pkUom+yKsXJ7c/kxxHcTEyvIurayA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sOtEv6TvhkPlFe78eOsSq1c8cNCBpnW6zf9p+uLiFo1EJm5A3Z0PtpmA3ASMdP4dk JgHQ6BYP9/vBN7Ng1+3cG1aFqlaRpu0t94isdeq7+jjQKw5VwNz2hWy1Drc0mAKJv7 T+8/kO4fvQG9ULJJBMTn/p6U1QIoc6TCULM43O8s= Message-ID: <4FECDE90.3020601@yandex.ru> Date: Fri, 29 Jun 2012 02:45:36 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Schwab Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 29.06.2012 2:32, Andreas Schwab wrote: > Dmitry Gutov writes: > >> Commands messing up existing window configuration is one of my top >> Emacs annoyances, and AFAIK it confuses the new users, too. >> Maybe nil check for (window-prev-buffers) should be instead included in >> `shrink-window-if-larger-than-buffer', with a way to override it? > > I think there should at least be an option to eliminate it completely. Eliminate the check, or the shrinking behavior? From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 29 03:16:49 2012 Received: (at 11810) by debbugs.gnu.org; 29 Jun 2012 07:16:49 +0000 Received: from localhost ([127.0.0.1]:36212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkVRh-0002zo-BL for submit@debbugs.gnu.org; Fri, 29 Jun 2012 03:16:49 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:44444) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkVRe-0002ze-HF for 11810@debbugs.gnu.org; Fri, 29 Jun 2012 03:16:47 -0400 Received: from frontend4.mail.m-online.net (unknown [192.168.8.183]) by mail-out.m-online.net (Postfix) with ESMTP id 3WNpwK72Skz4KK8b; Fri, 29 Jun 2012 09:12:47 +0200 (CEST) Received: from igel.home (ppp-88-217-106-247.dynamic.mnet-online.de [88.217.106.247]) by mail.mnet-online.de (Postfix) with ESMTPA id 3WNpvv0qTrzbbsH; Fri, 29 Jun 2012 09:12:27 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id B6F08CA2A4; Fri, 29 Jun 2012 09:12:26 +0200 (CEST) From: Andreas Schwab To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FECDE90.3020601@yandex.ru> X-Yow: HUMAN REPLICAS are inserted into VATS of NUTRITIONAL YEAST... Date: Fri, 29 Jun 2012 09:12:26 +0200 In-Reply-To: <4FECDE90.3020601@yandex.ru> (Dmitry Gutov's message of "Fri, 29 Jun 2012 02:45:36 +0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Dmitry Gutov writes: > On 29.06.2012 2:32, Andreas Schwab wrote: >> Dmitry Gutov writes: >> >>> Commands messing up existing window configuration is one of my top >>> Emacs annoyances, and AFAIK it confuses the new users, too. >>> Maybe nil check for (window-prev-buffers) should be instead included in >>> `shrink-window-if-larger-than-buffer', with a way to override it? >> >> I think there should at least be an option to eliminate it completely. > > Eliminate the check, or the shrinking behavior? The shrinking behavior. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 29 03:17:04 2012 Received: (at 11810) by debbugs.gnu.org; 29 Jun 2012 07:17:05 +0000 Received: from localhost ([127.0.0.1]:36216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SkVRw-00030g-Ns for submit@debbugs.gnu.org; Fri, 29 Jun 2012 03:17:04 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:51870) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SkVRu-00030J-L5 for 11810@debbugs.gnu.org; Fri, 29 Jun 2012 03:17:03 -0400 Received: (qmail invoked by alias); 29 Jun 2012 07:12:45 -0000 Received: from 62-47-62-215.adsl.highway.telekom.at (EHLO [62.47.62.215]) [62.47.62.215] by mail.gmx.net (mp029) with SMTP; 29 Jun 2012 09:12:45 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/GRip28JnGqtp/kH9uosfO0EEBqnMX+Iwd5fQ1aK VEhnjPAXNUoHug Message-ID: <4FED556A.4060702@gmx.at> Date: Fri, 29 Jun 2012 09:12:42 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> In-Reply-To: <4FECAF0F.1080307@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Commands messing up existing window configuration is one of my top > Emacs annoyances, and AFAIK it confuses the new users, too. > Maybe nil check for (window-prev-buffers) should be instead included in > `shrink-window-if-larger-than-buffer', with a way to override it? This problem has been previously discussed here http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00638.html If people want an option here, please decide on - the values it should take, and - how to meld it with `temp-buffer-resize-mode'. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 29 18:43:59 2012 Received: (at 11810) by debbugs.gnu.org; 29 Jun 2012 22:43:59 +0000 Received: from localhost ([127.0.0.1]:37919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Skjux-0007Gm-2l for submit@debbugs.gnu.org; Fri, 29 Jun 2012 18:43:59 -0400 Received: from forward5.mail.yandex.net ([77.88.46.21]:42137) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Skjus-0007Gc-OE for 11810@debbugs.gnu.org; Fri, 29 Jun 2012 18:43:57 -0400 Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward5.mail.yandex.net (Yandex) with ESMTP id 03AEF12017F6; Sat, 30 Jun 2012 02:39:32 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341009573; bh=lSxRf0UrMEw+X5qDY8Mj6OXLcnMGGR9M4TrWB/D0wzw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lcBwwn2HBZu3ZexNnXym8jPeDvHX4F1kgOvtYFoLzxjq4SmuHVD/z/wiHl2ScKPim eAVr655mA9Jlv7GSSo1X/6lg/MfDQAdAz1wpYAYnRfGet/VJfb4ZzzXgna6Tw653QE EXLN2MHDrhQp7zXlw8aWzyBia9JLmuS5QIllfOxc= Received: from smtp1.mail.yandex.net (localhost [127.0.0.1]) by smtp1.mail.yandex.net (Yandex) with ESMTP id C45E1AA056E; Sat, 30 Jun 2012 02:39:32 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp1.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dWAu4lbE-dWAWS1WR; Sat, 30 Jun 2012 02:39:32 +0400 X-Yandex-Rcpt-Suid: rudalics@gmx.at X-Yandex-Rcpt-Suid: 11810@debbugs.gnu.org X-Yandex-Rcpt-Suid: schwab@linux-m68k.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341009572; bh=lSxRf0UrMEw+X5qDY8Mj6OXLcnMGGR9M4TrWB/D0wzw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eJ57IYi3VaXKPIsPH32ERRUVAq7VhCKyH2jwk/ZOdCFd1ZeINcjqtz8G7sgWQxwHG zM+gs+1eVQs+Ks8PUIpDT+6QrLDf7n7Zhz1EhJ6YD7CwJ+5XiA+lXJNHrPCxI5+s+k BhzKaibQKuhnEJbQ0TKnNbAqm5KbCzpkaKblRo4c= Message-ID: <4FEE2EA5.5060905@yandex.ru> Date: Sat, 30 Jun 2012 02:39:33 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> In-Reply-To: <4FED556A.4060702@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: Andreas Schwab , 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Hi Martin, On 29.06.2012 11:12, martin rudalics wrote: > > Commands messing up existing window configuration is one of my top > > Emacs annoyances, and AFAIK it confuses the new users, too. > > Maybe nil check for (window-prev-buffers) should be instead included in > > `shrink-window-if-larger-than-buffer', with a way to override it? > > This problem has been previously discussed here > > http://lists.gnu.org/archive/html/emacs-devel/2010-08/msg00638.html > > If people want an option here, please decide on > > - the values it should take, and > > - how to meld it with `temp-buffer-resize-mode'. I think renaming and reusing `even-window-heights' is a good thing to do. I'd even suggest changing the default value, because, as you can see, virtually nobody among users knows about this variable: http://stackoverflow.com/questions/4716855/how-can-i-prevent-emacs-resizing-my-windows (Usually folks at SO give fairly comprehensive answers). And personally, I'd have been very happy to know about it about 1-2 years ago, before `pop-to-window' behavior strongly conditioned me against manually resizing windows. I don't think I've ever used `temp-buffer-resize-mode', but if it's a minor mode that a user has to enable explicitly, it should be fine if it overrides the value of `resize-windows-for-display'. Please note that `temp-buffer-resize-mode' already does the sane thing: it only resizes the window if the window is new and not reused. To answer you question in the last message: >> ! (let ((resize-windows-for-display nil)) >> ! (pop-to-buffer (current-buffer))) > > Here you explicitly override the user option - is that intentional? It's intentional, because `vc-diff-internal' calls `pop-to-buffer' before the diff command returns its full output, so the window height adjustment happens in `vc-diff-finish' which runs after the process returns. So you might want to account for this usage. Regarding "two similar approaches", I think just having an off by default `even-window-heights` variable and `temp-buffer-resize-mode' may satisfy more or less everyone, except there'd at least need to be a way to make shrinking asynchronous, as per above. -- Dmitry From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 30 05:14:18 2012 Received: (at 11810) by debbugs.gnu.org; 30 Jun 2012 09:14:18 +0000 Received: from localhost ([127.0.0.1]:38516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sktkw-0004Qv-35 for submit@debbugs.gnu.org; Sat, 30 Jun 2012 05:14:18 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:49904) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sktkt-0004Qo-Ta for 11810@debbugs.gnu.org; Sat, 30 Jun 2012 05:14:17 -0400 Received: (qmail invoked by alias); 30 Jun 2012 09:09:52 -0000 Received: from 62-47-37-44.adsl.highway.telekom.at (EHLO [62.47.37.44]) [62.47.37.44] by mail.gmx.net (mp028) with SMTP; 30 Jun 2012 11:09:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19y3ilivxVyakR7cQBQrj32+y9Sb6tG8Xk4s3NdIQ 8d1kTSS2lCAcBS Message-ID: <4FEEC259.7040308@gmx.at> Date: Sat, 30 Jun 2012 11:09:45 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> In-Reply-To: <4FEE2EA5.5060905@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: Andreas Schwab , 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > I think renaming and reusing `even-window-heights' is a good thing to > do. I'd even suggest changing the default value, because, as you can > see, virtually nobody among users knows about this variable: > > http://stackoverflow.com/questions/4716855/how-can-i-prevent-emacs-resizing-my-windows > > > (Usually folks at SO give fairly comprehensive answers). > And personally, I'd have been very happy to know about it about 1-2 > years ago, before `pop-to-window' behavior strongly conditioned me > against manually resizing windows. `even-window-heights' is one of these options pertaining to the classic two windows one-above-the-other frame layout. It should be redesigned to handle side-by-side windows and is largely obsolete anyway because you can now customize `window-combination-resize' instead. > I don't think I've ever used `temp-buffer-resize-mode', but if it's a > minor mode that a user has to enable explicitly, it should be fine if it > overrides the value of `resize-windows-for-display'. > Please note that `temp-buffer-resize-mode' already does the sane thing: > it only resizes the window if the window is new and not reused. `temp-buffer-resize-mode' adds `resize-temp-buffer-window' to `temp-buffer-window-show-hook' so it resizes the window even when it's reused. Or do I miss something? > To answer you question in the last message: > > >> ! (let ((resize-windows-for-display nil)) > >> ! (pop-to-buffer (current-buffer))) > > > > Here you explicitly override the user option - is that intentional? > > It's intentional, because `vc-diff-internal' calls `pop-to-buffer' > before the diff command returns its full output, so the window height > adjustment happens in `vc-diff-finish' which runs after the process > returns. So you might want to account for this usage. I don't recall the details but we always had a chicken-and-egg problem here: When you fill a buffer before displaying it you can't make its line breaks suit the window used for it. When you display it first, you can't make the window suit the line breaks of the buffer. And the number of line breaks determines the height of the region to display. > Regarding "two similar approaches", I think just having an off by > default `even-window-heights` variable and `temp-buffer-resize-mode' may > satisfy more or less everyone, except there'd at least need to be a way > to make shrinking asynchronous, as per above. Since I don't use `vc-diff' I can't really comment on how it should behave (I practically always use side-by-side windows for watching diffs). Is anyone interested in the resizing behavior at all? Couldn't we use the `quit-restore' window parameter to restore the original size of the window? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 30 17:39:24 2012 Received: (at 11810) by debbugs.gnu.org; 30 Jun 2012 21:39:24 +0000 Received: from localhost ([127.0.0.1]:39551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sl5Ny-0003Za-18 for submit@debbugs.gnu.org; Sat, 30 Jun 2012 17:39:24 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:36633) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sl5Nw-0003ZT-8d for 11810@debbugs.gnu.org; Sat, 30 Jun 2012 17:39:21 -0400 Received: by pbcwy7 with SMTP id wy7so5696553pbc.3 for <11810@debbugs.gnu.org>; Sat, 30 Jun 2012 14:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2GZ4rLhYztyubGatl3w6hV1dpbJjzmsLPvKM4HB2n2E=; b=jK4dCTE+O2XJTUIMjBgQgwKqPFsu6y94AO4lyNK4GElJfJGZawmO1G1FfSVa4X4PIF iMV69Vq5Qrlm1ZsgYV324NWHgmjyRJcozzST+P53ukNo9fg2SjrcKn1bESyCZ7fi5Lfb AODuSNY5LcxxOvRcz/Y+YKOxIDhrXXX9j7Al/AkuhVTdxLqA0VmAlQmV2atQo52vSi7J dc56eQLpWXiS0ICKr+nh9Yk6CdRCVGZVMm0FFy5ZRxxoPDr2UAVpEFYosWJMfePB1VdY z3nnPnH8ak2FMDwhdnT2NDCSMCOZ2ZkVS4d4TRk626E5j4XGAiQGEIfzy4nsiE9s6uzN ANQA== Received: by 10.68.201.7 with SMTP id jw7mr18090727pbc.60.1341092093693; Sat, 30 Jun 2012 14:34:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.162.16 with HTTP; Sat, 30 Jun 2012 14:34:13 -0700 (PDT) In-Reply-To: <4FEEC259.7040308@gmx.at> References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> From: Juanma Barranquero Date: Sat, 30 Jun 2012 23:34:13 +0200 Message-ID: Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 11810 Cc: Andreas Schwab , 11810@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Sat, Jun 30, 2012 at 11:09 AM, martin rudalics wrote: > Is anyone interested in the resizing behavior at all? IIUC what's being discussed, yes, definitely. =C2=A0 =C2=A0 Juanma From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 30 19:22:45 2012 Received: (at 11810) by debbugs.gnu.org; 30 Jun 2012 23:22:45 +0000 Received: from localhost ([127.0.0.1]:39615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sl701-0005rV-1a for submit@debbugs.gnu.org; Sat, 30 Jun 2012 19:22:45 -0400 Received: from forward13.mail.yandex.net ([95.108.130.120]:56928) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sl6zx-0005rL-59 for 11810@debbugs.gnu.org; Sat, 30 Jun 2012 19:22:43 -0400 Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward13.mail.yandex.net (Yandex) with ESMTP id BBFC0141823; Sun, 1 Jul 2012 03:18:13 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341098293; bh=pIvwQH7ZbxgM07+cTyEfBFzX+k20sQ7ncSPLkQ2fmMs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=RRXi2xkUNe3/bUHZZAMsSX5X8gdwMBwqwKjbgRA36hExMn2OKm8+peKKbqSoBgXPJ 9GBzL5L9jm1K0FdzP34vi/3SsV8JhhBo4wj1N1NEKaK7ee+/0MCbHyrY1wW211Rkuk w6EHuZyvV7dFoPqV0NB+6X8FqZtE5ACoMcYOBjho= Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 770381B60769; Sun, 1 Jul 2012 03:18:13 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ID7GQZQO-ID7eJHpT; Sun, 1 Jul 2012 03:18:13 +0400 X-Yandex-Rcpt-Suid: rudalics@gmx.at X-Yandex-Rcpt-Suid: 11810@debbugs.gnu.org X-Yandex-Rcpt-Suid: schwab@linux-m68k.org X-Yandex-Rcpt-Suid: lekktu@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341098293; bh=pIvwQH7ZbxgM07+cTyEfBFzX+k20sQ7ncSPLkQ2fmMs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Q/q5FeoqEKyM6kmCJK2dXRRS2ElQJPyd2ZjZlYoYLe6a2ewAu9xIqJZWDVtaJpPgX zyNP4rEeuJT12juRNMs3DXkzGFc9e9byP0SZs0iAh6tP/lPqqay7njb8HijcoICh3w zbR+mg0/PGx13ryzXFDPf7OiXhPuyrMvdobUmqi4= Message-ID: <4FEF8935.9010508@yandex.ru> Date: Sun, 01 Jul 2012 03:18:13 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> In-Reply-To: <4FEEC259.7040308@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: Juanma Barranquero , Andreas Schwab , 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 30.06.2012 13:09, martin rudalics wrote: > `even-window-heights' is one of these options pertaining to the classic > two windows one-above-the-other frame layout. It should be redesigned > to handle side-by-side windows and is largely obsolete anyway because > you can now customize `window-combination-resize' instead. How is it obsolete? As far as I can see, neither of the two possible values of `window-combination-resize' says "don't resize my existing windows until specifically asked". > > I don't think I've ever used `temp-buffer-resize-mode', but if it's a > > minor mode that a user has to enable explicitly, it should be fine if it > > overrides the value of `resize-windows-for-display'. > > Please note that `temp-buffer-resize-mode' already does the sane thing: > > it only resizes the window if the window is new and not reused. > > `temp-buffer-resize-mode' adds `resize-temp-buffer-window' to > `temp-buffer-window-show-hook' so it resizes the window even when it's > reused. Or do I miss something? Actually yes, I haven't tested it properly the last time. It can shrink the window to make it fit the buffer, but it restores the window's size when it's done, which is the important thing. > > To answer you question in the last message: > > > > >> ! (let ((resize-windows-for-display nil)) > > >> ! (pop-to-buffer (current-buffer))) > > > > > > Here you explicitly override the user option - is that intentional? > > > > It's intentional, because `vc-diff-internal' calls `pop-to-buffer' > > before the diff command returns its full output, so the window height > > adjustment happens in `vc-diff-finish' which runs after the process > > returns. So you might want to account for this usage. > > I don't recall the details but we always had a chicken-and-egg problem > here: When you fill a buffer before displaying it you can't make its > line breaks suit the window used for it. When you display it first, you > can't make the window suit the line breaks of the buffer. And the > number of line breaks determines the height of the region to display. Do you mean auto-filling, as in, "inserting hard newlines"? I don't think diff-mode does that. It does pop a window immediately, but probably just because it would be weird to see a window pop up only after the diff command finishes (if that happens after some time has passed). > > Regarding "two similar approaches", I think just having an off by > > default `even-window-heights` variable and `temp-buffer-resize-mode' may > > satisfy more or less everyone, except there'd at least need to be a way > > to make shrinking asynchronous, as per above. > > Since I don't use `vc-diff' I can't really comment on how it should > behave (I practically always use side-by-side windows for watching > diffs). Is anyone interested in the resizing behavior at all? Couldn't > we use the `quit-restore' window parameter to restore the original size > of the window? We probably could, if solving only this particular case is okay. As far as VC package goes, we'd need to do that in `vc-diff-internal' and in all (?) callers of `vc-log-internal-common'. -- Dmitry From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 01 05:10:51 2012 Received: (at 11810) by debbugs.gnu.org; 1 Jul 2012 09:10:51 +0000 Received: from localhost ([127.0.0.1]:39817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SlGB8-0001xC-9N for submit@debbugs.gnu.org; Sun, 01 Jul 2012 05:10:51 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:42555) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SlGB4-0001x3-Tf for 11810@debbugs.gnu.org; Sun, 01 Jul 2012 05:10:48 -0400 Received: (qmail invoked by alias); 01 Jul 2012 09:06:16 -0000 Received: from 62-47-56-215.adsl.highway.telekom.at (EHLO [62.47.56.215]) [62.47.56.215] by mail.gmx.net (mp028) with SMTP; 01 Jul 2012 11:06:16 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+jWE9zh3yjxADmUoPpRsOtpG0eGSExAThRUbayKF wof5r+dIZxfNTu Message-ID: <4FF012FE.1010502@gmx.at> Date: Sun, 01 Jul 2012 11:06:06 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> <4FEF8935.9010508@yandex.ru> In-Reply-To: <4FEF8935.9010508@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: Juanma Barranquero , Andreas Schwab , 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > How is it obsolete? As far as I can see, neither of the two possible > values of `window-combination-resize' says "don't resize my existing > windows until specifically asked". You would customize `window-combination-resize' only with `even-window-heights' implicitly nil. >> `temp-buffer-resize-mode' adds `resize-temp-buffer-window' to >> `temp-buffer-window-show-hook' so it resizes the window even when it's >> reused. Or do I miss something? > > Actually yes, I haven't tested it properly the last time. > It can shrink the window to make it fit the buffer, but it restores the > window's size when it's done, which is the important thing. It explicitly checks whether `temp-buffer-resize-mode' is on when the buffer shall be removed. >> I don't recall the details but we always had a chicken-and-egg problem >> here: When you fill a buffer before displaying it you can't make its >> line breaks suit the window used for it. When you display it first, you >> can't make the window suit the line breaks of the buffer. And the >> number of line breaks determines the height of the region to display. > > Do you mean auto-filling, as in, "inserting hard newlines"? I don't > think diff-mode does that. It does pop a window immediately, but > probably just because it would be weird to see a window pop up only > after the diff command finishes (if that happens after some time has > passed). Must have been a different problem indeed, probably in the context of man or woman, IIRC. >> Couldn't >> we use the `quit-restore' window parameter to restore the original size >> of the window? > > We probably could, if solving only this particular case is okay. As far > as VC package goes, we'd need to do that in `vc-diff-internal' and in > all (?) callers of `vc-log-internal-common'. We could simply remove the `temp-buffer-resize-mode' check in `quit-window'. I hardly understand what implications this might have. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 01 05:11:21 2012 Received: (at 11810) by debbugs.gnu.org; 1 Jul 2012 09:11:21 +0000 Received: from localhost ([127.0.0.1]:39821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SlGBd-0001yG-2k for submit@debbugs.gnu.org; Sun, 01 Jul 2012 05:11:21 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:53231) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SlGBb-0001y8-0E for 11810@debbugs.gnu.org; Sun, 01 Jul 2012 05:11:19 -0400 Received: (qmail invoked by alias); 01 Jul 2012 09:06:48 -0000 Received: from 62-47-56-215.adsl.highway.telekom.at (EHLO [62.47.56.215]) [62.47.56.215] by mail.gmx.net (mp031) with SMTP; 01 Jul 2012 11:06:48 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19bqOB/JxNb1I4LGI36o4tQnVdx8a5KSZKb34tDYK xqJnQVQEU5ofv7 Message-ID: <4FF0131F.6040705@gmx.at> Date: Sun, 01 Jul 2012 11:06:39 +0200 From: martin rudalics MIME-Version: 1.0 To: Juanma Barranquero Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: Andreas Schwab , 11810@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Is anyone interested in the resizing behavior at all? > > IIUC what's being discussed, yes, definitely. I was unclear. I meant resizing the window when it gets _reused_. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 02 09:37:45 2012 Received: (at 11810) by debbugs.gnu.org; 2 Jul 2012 13:37:46 +0000 Received: from localhost ([127.0.0.1]:41704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Slgoz-0002rV-Ec for submit@debbugs.gnu.org; Mon, 02 Jul 2012 09:37:45 -0400 Received: from forward12.mail.yandex.net ([95.108.130.94]:43405) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Slgov-0002rL-58 for 11810@debbugs.gnu.org; Mon, 02 Jul 2012 09:37:43 -0400 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= 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) 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= Message-ID: <4FF1A30F.4090806@yandex.ru> Date: Mon, 02 Jul 2012 17:33:03 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF146F4.1080103@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 02 12:36:34 2012 Received: (at 11810) by debbugs.gnu.org; 2 Jul 2012 16:36:34 +0000 Received: from localhost ([127.0.0.1]:42292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sljc2-0007lR-7M for submit@debbugs.gnu.org; Mon, 02 Jul 2012 12:36:34 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:55749) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sljbz-0007lJ-Tf for 11810@debbugs.gnu.org; Mon, 02 Jul 2012 12:36:33 -0400 Received: (qmail invoked by alias); 02 Jul 2012 16:31:54 -0000 Received: from 62-47-50-61.adsl.highway.telekom.at (EHLO [62.47.50.61]) [62.47.50.61] by mail.gmx.net (mp020) with SMTP; 02 Jul 2012 18:31:54 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+TLUYcoayT1Y84kgzUTrdUu/9ThRkJwJKNbZpGE1 MrT32vxHp6qUje Message-ID: <4FF1CD2C.5000704@gmx.at> Date: Mon, 02 Jul 2012 18:32:44 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF1A30F.4090806@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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). Not necessarily: When you have two windows one above the other and `display-buffer' splits the upper one (thresholds permitting) and then `vc-diff' temporarily resizes the middle one, it steals space from the lower window. When quitting the middle window, that space is returned to the upper one. >> (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. Sure, but ... >> (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. ... in this case we can be sure that the user changed the size so we probably should leave it alone. > Would it be harder to *not set* the 'quit-restore parameter in cases > when we don't want the configuration restored, instead? The whole idea of quitting is to get as much as possible of the state that existed before some temporal change without, however, rescinding changes introduced by user. > 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"? When watching diffs I usually very soon want to concentrate on the modified file and its changes. For that reason, I sometimes want to enlarge its window and not have `quit-window' shrink it to what it was before invoking vc-diff. But this use case might be sufficiently exotic to dismiss it. >> > 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. It would be a hack anyway. >> > 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? Don't we? How would the (when resize ...) check affect the rest? And keep in mind that any resize operation has to take into account that the frame configuration or size has changed in the meantime. > 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. What and where is `vc-log-print'? > 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? I don't know. I think a vc-diff buffer should be considerded a temporary buffer, subject to `temp-buffer-resize-mode'. Ideally, windows of non-temporary buffers are never shrunk automatically. >> (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. I miss you here. The information is there (otherwise your patch couldn't use it) and I'd just use it in the additional case where `even-window-heights' is set. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 02 16:44:23 2012 Received: (at 11810) by debbugs.gnu.org; 2 Jul 2012 20:44:23 +0000 Received: from localhost ([127.0.0.1]:43420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SlnTq-0007i7-KJ for submit@debbugs.gnu.org; Mon, 02 Jul 2012 16:44:23 -0400 Received: from forward13.mail.yandex.net ([95.108.130.120]:43279) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SlnTk-0007hv-RX for 11810@debbugs.gnu.org; Mon, 02 Jul 2012 16:44:19 -0400 Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward13.mail.yandex.net (Yandex) with ESMTP id B7A05141931; Tue, 3 Jul 2012 00:39:37 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341261577; bh=L4/2+aAYOjmOCpWRcrlPUsBv7h+hMGZTB3J3KMzKunE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qTbWRQvS+C4MgS0zQ79DO/HLjKi1VYEpOdO1tanX4POslB5YbeZ6FJ3712UmLO6Og Tl9yNF8ZCI1qsCOnuJiJjHvB4Bc9xYS8tLxf92isjeNSNJGywziDHBKWUHW3dT6IOI TYDQjJwCcPLKdeUuhE3NvCxukyvh4dzYJJopwhe4= Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 874C67E03BA; Tue, 3 Jul 2012 00:39:37 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dbVu512q-dbVi5Fma; Tue, 3 Jul 2012 00:39:37 +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=1341261577; bh=L4/2+aAYOjmOCpWRcrlPUsBv7h+hMGZTB3J3KMzKunE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iSEa6adNajpRIK4CUmDcUHJNMhaVUJRzn0rIaN6CnuYagpQGtfFUvrZcS2w5zfUCa X5HxJWHDqaP04boWeX9lqfFyinaJW+9UIP05/16NTunDNaaWSeBAGnUYYuaqZeFHfX jrz1SbPKWstzlq8NOkkjdTil2tp9sszty5dtM59M= Message-ID: <4FF206F5.4030101@yandex.ru> Date: Tue, 03 Jul 2012 00:39:17 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF1CD2C.5000704@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org, emacs-devel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 02.07.2012 20:32, martin rudalics wrote: > > 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). > > Not necessarily: When you have two windows one above the other and > `display-buffer' splits the upper one (thresholds permitting) and then > `vc-diff' temporarily resizes the middle one, it steals space from the > lower window. When quitting the middle window, that space is returned > to the upper one. I guess that's true, my height threshold is just too high for that. A bit inconsistent, though, isn't it? Stealing space from the lower, returning to the upper. > >> (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. > > Sure, but ... > > >> (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. > > ... in this case we can be sure that the user changed the size so we > probably should leave it alone. That depends on the definition of "the user". In our case, *I* didn't explicitly resize the window, `vc-diff' did. > > Would it be harder to *not set* the 'quit-restore parameter in cases > > when we don't want the configuration restored, instead? > > The whole idea of quitting is to get as much as possible of the state > that existed before some temporal change without, however, rescinding > changes introduced by user. How about clearing (or changing) the 'quit-window parameter in each command when we're sure that the user won't want to have the size restored afterwards? There would be a set of "user-facing" functions that would do that. > > 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"? > > When watching diffs I usually very soon want to concentrate on the > modified file and its changes. For that reason, I sometimes want to > enlarge its window and not have `quit-window' shrink it to what it was > before invoking vc-diff. But this use case might be sufficiently exotic > to dismiss it. How will the temp-buffer-resize-mode null check help in this case? It's a global minor mode, so it's either t in all buffers, or nil in all of them. > >> > 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? > > Don't we? How would the (when resize ...) check affect the rest? And > keep in mind that any resize operation has to take into account that the > frame configuration or size has changed in the meantime. Eh, I meant the comparison will blow up, it's above the condition-case: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) /=(nil 42) eval((/= nil 42) nil) > > 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. > > What and where is `vc-log-print'? Sorry, `vc-print-log'. C-x v l. > > 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? > > I don't know. I think a vc-diff buffer should be considerded a > temporary buffer, subject to `temp-buffer-resize-mode'. Ideally, > windows of non-temporary buffers are never shrunk automatically. 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"? > >> (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. > > I miss you here. The information is there (otherwise your patch > couldn't use it) and I'd just use it in the additional case where > `even-window-heights' is set. I misunderstood. Re-resizing to the original height would work, of course. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 03 03:19:34 2012 Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 07:19:34 +0000 Received: from localhost ([127.0.0.1]:44154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SlxOX-0005tU-D5 for submit@debbugs.gnu.org; Tue, 03 Jul 2012 03:19:33 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:56776) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SlxOU-0005tL-Fo for 11810@debbugs.gnu.org; Tue, 03 Jul 2012 03:19:31 -0400 Received: (qmail invoked by alias); 03 Jul 2012 07:14:49 -0000 Received: from 62-47-32-248.adsl.highway.telekom.at (EHLO [62.47.32.248]) [62.47.32.248] by mail.gmx.net (mp069) with SMTP; 03 Jul 2012 09:14:49 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/QaD5QnH/Q+C0zBinNolM/WifMwuwrD96ljkO+KM 6/iwomHLqJoMvH Message-ID: <4FF29BE7.2030006@gmx.at> Date: Tue, 03 Jul 2012 09:14:47 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF206F5.4030101@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > A bit inconsistent, though, isn't it? Stealing space from the lower, > returning to the upper. When you resize the selected window you try to steal from/give to the lower window in order to not clobber the window-start position of the selected window. When you delete a window you return space to the upper one because that's where the space usually came from. That's just my interpretation of the behavior, though. >> >> (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. >> >> ... in this case we can be sure that the user changed the size so we >> probably should leave it alone. > > That depends on the definition of "the user". In our case, *I* didn't > explicitly resize the window, `vc-diff' did. Because of `even-window-heights'? That's something I obviously forgot 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 (2) `window--even-window-heights' actually did resize the window and don't do the `temp-buffer-resize-mode' check in `quit-window'. > How about clearing (or changing) the 'quit-window parameter in each > command when we're sure that the user won't want to have the size > restored afterwards? > There would be a set of "user-facing" functions that would do that. `adjust-window-trailing-edge' would be an obvious candidate. But which window's parameter would you clear? Both? > How will the temp-buffer-resize-mode null check help in this case? > It's a global minor mode, so it's either t in all buffers, or nil in all > of them. That's why I would have set `temp-buffer-resize-mode' buffer-locally to t. But it's ugly. >> Don't we? How would the (when resize ...) check affect the rest? And >> keep in mind that any resize operation has to take into account that the >> frame configuration or size has changed in the meantime. > > Eh, I meant the comparison will blow up, it's above the condition-case: > > Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) > /=(nil 42) > eval((/= nil 42) nil) I see. This would have to be fixed anyway if the third element of the quit-restore parameter is not set in `display-buffer-record-window'. >> > 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. >> >> What and where is `vc-log-print'? > > Sorry, `vc-print-log'. C-x v l. It's in `vc-log-internal-common', I see. >> I don't know. I think a vc-diff buffer should be considerded a >> temporary buffer, subject to `temp-buffer-resize-mode'. Ideally, >> windows of non-temporary buffers are never shrunk automatically. > > 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? martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 03 08:53:01 2012 Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 12:53:01 +0000 Received: from localhost ([127.0.0.1]:44833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm2bF-0006fN-5a for submit@debbugs.gnu.org; Tue, 03 Jul 2012 08:53:01 -0400 Received: from forward13.mail.yandex.net ([95.108.130.120]:47020) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm2bB-0006fF-M3 for 11810@debbugs.gnu.org; Tue, 03 Jul 2012 08:53:00 -0400 Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward13.mail.yandex.net (Yandex) with ESMTP id EFD9D142655; Tue, 3 Jul 2012 16:48:12 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341319693; bh=nMXwv4dpYVA90npAQWhqqTuMZrEsIJGeXXAtwj+pCaw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YjEHbw6W4VsSxqjpdCRztsjsBTP7XMGd3n5NO6vJ+CotpZ7LjPWJXhJu7A7wX3KK5 xpQxdwFmmcniNWi09RMvmGZ/zLqVVfA4PGR4WHJvQFISubWP2XFAdkRlJU6l4HUBjn UbgNKlHVBd3sfqYMBs8ehuEIsKebFbialp/pLvF0= Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id CEB561B60267; Tue, 3 Jul 2012 16:48:12 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id mC7GAc8B-mC7SLpt6; Tue, 3 Jul 2012 16:48:12 +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=1341319692; bh=nMXwv4dpYVA90npAQWhqqTuMZrEsIJGeXXAtwj+pCaw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=F6crqkhWBPJxYxL8oaJa3z0iursZ/pas71rryheWfaTwxGOUSKzjPOtt8viedaw2y Jwnq39kSixagh0MaJ85hiIjqmVenTW6no71UorEJ7FShTleo0tH5QGBz3x5aJo9lO4 efCZ8g7r+UWP6affdwf3W2dU4jYp6wV0hoDvFrIo= Message-ID: <4FF2EA0D.9030006@yandex.ru> Date: Tue, 03 Jul 2012 16:48:13 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF29BE7.2030006@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 03.07.2012 11:14, martin rudalics wrote: > >> >> (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. > >> > >> ... in this case we can be sure that the user changed the size so we > >> probably should leave it alone. > > > > That depends on the definition of "the user". In our case, *I* didn't > > explicitly resize the window, `vc-diff' did. > > Because of `even-window-heights'? That's something I obviously forgot Because of `shrink-window-if-larger-than-buffer'. `even-window-heights' could have contributed in another case, if my windows were not of equal height already. > 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. > (2) `window--even-window-heights' actually did resize the window > > and don't do the `temp-buffer-resize-mode' check in `quit-window'. > > > How about clearing (or changing) the 'quit-window parameter in each > > command when we're sure that the user won't want to have the size > > restored afterwards? > > There would be a set of "user-facing" functions that would do that. > > `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. > > How will the temp-buffer-resize-mode null check help in this case? > > It's a global minor mode, so it's either t in all buffers, or nil in all > > of them. > > That's why I would have set `temp-buffer-resize-mode' buffer-locally to > t. But it's ugly. 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. > >> I don't know. I think a vc-diff buffer should be considerded a > >> temporary buffer, subject to `temp-buffer-resize-mode'. Ideally, > >> windows of non-temporary buffers are never shrunk automatically. > > > > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 03 12:45:21 2012 Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 16:45:21 +0000 Received: from localhost ([127.0.0.1]:45476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sm6E4-0004Jx-Kq for submit@debbugs.gnu.org; Tue, 03 Jul 2012 12:45:21 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:38553) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sm6Dz-0004Jb-8W for 11810@debbugs.gnu.org; Tue, 03 Jul 2012 12:45:16 -0400 Received: (qmail invoked by alias); 03 Jul 2012 16:40:32 -0000 Received: from 62-47-56-5.adsl.highway.telekom.at (EHLO [62.47.56.5]) [62.47.56.5] by mail.gmx.net (mp038) with SMTP; 03 Jul 2012 18:40:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19IhMQWXyJImKt+AwOYeJIXs4/OjQbieD7Zxs1HCK iFvyKxQxt4/62R Message-ID: <4FF3207B.1050609@gmx.at> Date: Tue, 03 Jul 2012 18:40:27 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF2EA0D.9030006@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > That depends on the definition of "the user". In our case, *I* didn't >> > explicitly resize the window, `vc-diff' did. >> >> Because of `even-window-heights'? That's something I obviously forgot > > 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. > `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'. >> 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. >> `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. > 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. 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. >> > 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, 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. Another way is to explicitly call `resize-temp-buffer-window' and set `temp-buffer-resize-mode' t in that buffer. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 03 15:01:01 2012 Received: (at 11810) by debbugs.gnu.org; 3 Jul 2012 19:01:01 +0000 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 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 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= 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) 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= Message-ID: <4FF3404E.6000207@yandex.ru> Date: Tue, 03 Jul 2012 22:56:14 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF3207B.1050609@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 04 05:23:18 2012 Received: (at 11810) by debbugs.gnu.org; 4 Jul 2012 09:23:18 +0000 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 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 Received: (qmail invoked by alias); 04 Jul 2012 09:18:28 -0000 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 Message-ID: <4FF40A6C.2050601@gmx.at> Date: Wed, 04 Jul 2012 11:18:36 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF3404E.6000207@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > > 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 04 12:17:49 2012 Received: (at 11810) by debbugs.gnu.org; 4 Jul 2012 16:17:49 +0000 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 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 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= 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) 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= Message-ID: <4FF46B89.5040301@yandex.ru> Date: Wed, 04 Jul 2012 20:12:57 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> In-Reply-To: <4FF40A6C.2050601@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 05 05:58:32 2012 Received: (at 11810) by debbugs.gnu.org; 5 Jul 2012 09:58:32 +0000 Received: from localhost ([127.0.0.1]:49715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmipU-00007b-Cu for submit@debbugs.gnu.org; Thu, 05 Jul 2012 05:58:32 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:53961) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SmipR-00007T-Pr for 11810@debbugs.gnu.org; Thu, 05 Jul 2012 05:58:30 -0400 Received: (qmail invoked by alias); 05 Jul 2012 09:53:37 -0000 Received: from 62-47-44-165.adsl.highway.telekom.at (EHLO [62.47.44.165]) [62.47.44.165] by mail.gmx.net (mp012) with SMTP; 05 Jul 2012 11:53:37 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18pgTIoNC8pyazvxomys+eQeiPTMn6yqlsR7RUsuY CC2I8bV8687557 Message-ID: <4FF56410.7000705@gmx.at> Date: Thu, 05 Jul 2012 11:53:20 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> <4FF46B89.5040301@yandex.ru> In-Reply-To: <4FF46B89.5040301@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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'. I think we could do (when window (prog1 (window--display-buffer buffer window 'reuse) (window--even-window-heights window))) in `display-buffer-use-some-window'. > Maybe that's fine, I'll just set the variable to nil. OK > 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. I'm more concerned with the fact that an application might reuse the shrunk window via `display-buffer'. > If someone wants `shrink-window-if-...' to have no effect only in > `vc-diff', well, that's a different goal. But that's probably what some people want. >> 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. Can you install it? Else please post the patch and a ChangeLog entry. >> (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. We need a susbstitute for `with-output-to-temp-buffer' for asynchronously filled buffers. martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 05 19:24:36 2012 Received: (at 11810) by debbugs.gnu.org; 5 Jul 2012 23:24:36 +0000 Received: from localhost ([127.0.0.1]:51145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmvPX-0000WS-M8 for submit@debbugs.gnu.org; Thu, 05 Jul 2012 19:24:36 -0400 Received: from forward3.mail.yandex.net ([77.88.46.8]:59751) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SmvPU-0000WH-LD for 11810@debbugs.gnu.org; Thu, 05 Jul 2012 19:24:34 -0400 Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward3.mail.yandex.net (Yandex) with ESMTP id 82A79B41646; Fri, 6 Jul 2012 03:19:33 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341530376; bh=Hl9FNuQe8OyHGa9g2GSls7N9HP9LP17vgagANfELqCs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=a9x5en1ZMPTo/84SCteQnYEwyKJhm3/ggN6e03/6zCvqbj54KG1sWCaBpHWTdHom+ wTwvPNQ28pWEvjd+d9a7/d+DA5FWRJ2zd0VV6Yf4kdAnFd6KZUKtIE8Cv1JWc5T+E5 Xx5RikNRC7U4q9FTBgkqbZelxjXwmGwhJaBuXzdA= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 60E9EE2057B; Fri, 6 Jul 2012 03:19:33 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id JWYeKIoq-JWYSLOHM; Fri, 6 Jul 2012 03:19:33 +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=1341530373; bh=Hl9FNuQe8OyHGa9g2GSls7N9HP9LP17vgagANfELqCs=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=Slv6bndOou2nUIt2lCX19y1Z4qCGTugmBrFFcZOmX9R3XPHuldaM1Rcnw6Z4wiSLi N4wSPYEFFcvYTgy2CO2IPIgu0+ipKfHeNq49hWGXFig0/mioPvrnRT7wu0gXTKvIye nhrsPNN3zKhuGaD54zD/U+mg30I639Fy6nu70dqQ= Message-ID: <4FF62109.6000608@yandex.ru> Date: Fri, 06 Jul 2012 03:19:37 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> <4FF46B89.5040301@yandex.ru> <4FF56410.7000705@gmx.at> In-Reply-To: <4FF56410.7000705@gmx.at> Content-Type: multipart/mixed; boundary="------------010102080402090501070203" X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------010102080402090501070203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05.07.2012 13:53, martin rudalics wrote: > > 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'. > > I think we could do > > (when window > (prog1 > (window--display-buffer buffer window 'reuse) > (window--even-window-heights window))) > > in `display-buffer-use-some-window'. That should work, but IMO `even-window-heights' behavior is just too surprising (with its conditions on window positions), so, if you don't mind, I'll open another bug with proposal to change its default value, presenting the above as alternative. > > 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. > > I'm more concerned with the fact that an application might reuse the > shrunk window via `display-buffer'. In this case, unless the new buffer is the same as the one already displayed in the shrunk window, `display-buffer-record-window' will overwrite the 'quit-restore parameter, so I don't see what the problem scenario would be. Hadn't managed to reproduce one either. > > If someone wants `shrink-window-if-...' to have no effect only in > > `vc-diff', well, that's a different goal. > > But that's probably what some people want. I don't think we've seen a request exactly like that yet, but that would require a vc-prefixed variable. Asynchronous `with-output-to-temp-buffer' proposal is better in that regard. > >> 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. > > Can you install it? Else please post the patch and a ChangeLog entry. Nope. Is unified diff okay? window.el (quit-window): Always restore window height when it's saved in quit-restore parameter. -- Dmitry --------------010102080402090501070203 Content-Type: text/plain; charset=windows-1251; name="quit-window.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="quit-window.diff" diff --git a/lisp/window.el b/lisp/window.el index b362f40..f9adf84 100644 --- a/lisp/window.el +++ b/lisp/window.el @@ -3069,9 +3069,8 @@ one. If non-nil, reset `quit-restore' parameter to nil." (buffer-live-p (car quad)) (eq (nth 3 quit-restore) buffer)) ;; Show another buffer stored in quit-restore parameter. - (setq resize (with-current-buffer buffer - (and temp-buffer-resize-mode - (/= (nth 3 quad) (window-total-size window))))) + (setq resize (and (integerp (nth 3 quad)) + (/= (nth 3 quad) (window-total-size window)))) (set-window-dedicated-p window nil) (when resize ;; Try to resize WINDOW to its old height but don't signal an --------------010102080402090501070203-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 06 02:41:32 2012 Received: (at 11810) by debbugs.gnu.org; 6 Jul 2012 06:41:32 +0000 Received: from localhost ([127.0.0.1]:51347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sn2EO-0001oN-3Q for submit@debbugs.gnu.org; Fri, 06 Jul 2012 02:41:32 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:48049) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sn2EM-0001oG-3W for 11810@debbugs.gnu.org; Fri, 06 Jul 2012 02:41:31 -0400 Received: (qmail invoked by alias); 06 Jul 2012 06:36:32 -0000 Received: from 62-47-51-37.adsl.highway.telekom.at (EHLO [62.47.51.37]) [62.47.51.37] by mail.gmx.net (mp034) with SMTP; 06 Jul 2012 08:36:32 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX194TbkdDyp4Xb6hTqpTvFqQgPudpbz6VlrtMITLxw tEOgvGGEbc2Ynk Message-ID: <4FF6876E.2050904@gmx.at> Date: Fri, 06 Jul 2012 08:36:30 +0200 From: martin rudalics MIME-Version: 1.0 To: Dmitry Gutov Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> <4FF46B89.5040301@yandex.ru> <4FF56410.7000705@gmx.at> <4FF62109.6000608@yandex.ru> In-Reply-To: <4FF62109.6000608@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.3 (/) > That should work, but IMO `even-window-heights' behavior is just too > surprising (with its conditions on window positions), so, if you don't > mind, I'll open another bug with proposal to change its default value, > presenting the above as alternative. OK >> I'm more concerned with the fact that an application might reuse the >> shrunk window via `display-buffer'. > > In this case, unless the new buffer is the same as the one already > displayed in the shrunk window, `display-buffer-record-window' will > overwrite the 'quit-restore parameter, so I don't see what the problem > scenario would be. Hadn't managed to reproduce one either. Consider users with always <= 2 windows per frame: If `display-buffer' displays some temporary buffer in the other, reused window, shrinking it to some few lines, calling `switch-to-buffer-other-window' in that situation won't be of much fun. >> > If someone wants `shrink-window-if-...' to have no effect only in >> > `vc-diff', well, that's a different goal. >> >> But that's probably what some people want. > > I don't think we've seen a request exactly like that yet, but that would > require a vc-prefixed variable. When we get such a request you'll take care of it ;-) > window.el (quit-window): Always restore window height when it's saved in > quit-restore parameter. Installed as revision 108897. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 06 08:31:22 2012 Received: (at 11810) by debbugs.gnu.org; 6 Jul 2012 12:31:22 +0000 Received: from localhost ([127.0.0.1]:51610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sn7gv-0003gU-5k for submit@debbugs.gnu.org; Fri, 06 Jul 2012 08:31:22 -0400 Received: from forward14.mail.yandex.net ([95.108.130.92]:56396) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sn7gr-0003gJ-2f for 11810@debbugs.gnu.org; Fri, 06 Jul 2012 08:31:19 -0400 Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward14.mail.yandex.net (Yandex) with ESMTP id 6A13D1982974; Fri, 6 Jul 2012 16:26:17 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1341577577; bh=LzCnXhgeMhynza3FNp9zrAbouGLlHn756AHaui4cBzo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=O9qeMXAqQc9GfPCUYZ2ycpT4synvoVghTIOl8225nzIohHU4cVSkxYuc5VSmtF0WG vjAYHC0KLn4t3U5raZiHcgY3gzgx3CRlFPt8O1W4x3c2bevHnvLSLpqLRlfO5PgtSa Ky6jXHffFtFNh12kTXZNIpniLpfavACEtSRcdO5I= Received: from smtp11.mail.yandex.net (localhost [127.0.0.1]) by smtp11.mail.yandex.net (Yandex) with ESMTP id 4848F7E00C3; Fri, 6 Jul 2012 16:26:17 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp11.mail.yandex.net (nwsmtp/Yandex) with ESMTP id QGVuVCFB-QGVudMdK; Fri, 6 Jul 2012 16:26:16 +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=1341577577; bh=LzCnXhgeMhynza3FNp9zrAbouGLlHn756AHaui4cBzo=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DzjpZtyNEPQgSpyJ5bM92Ywql8j5Em8n/b/dWS2L2Z6VsvbY4M7NfqJsSc7urg5NP yoY4ZgyP3aW8eKgea6wJ1rV+FhUcUAfnn4bYcwqZR/mM8wfQJ3IoHXKXvmxtN9wlxJ uYCeYT3WYPEqRIi2TNgRrtg7F4l+NC+sxVSilOt4= Message-ID: <4FF6D955.9010908@yandex.ru> Date: Fri, 06 Jul 2012 16:25:57 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: martin rudalics Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> <4FF46B89.5040301@yandex.ru> <4FF56410.7000705@gmx.at> <4FF62109.6000608@yandex.ru> <4FF6876E.2050904@gmx.at> In-Reply-To: <4FF6876E.2050904@gmx.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810 Cc: 11810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 06.07.2012 10:36, martin rudalics wrote: > >> I'm more concerned with the fact that an application might reuse the > >> shrunk window via `display-buffer'. > > > > In this case, unless the new buffer is the same as the one already > > displayed in the shrunk window, `display-buffer-record-window' will > > overwrite the 'quit-restore parameter, so I don't see what the problem > > scenario would be. Hadn't managed to reproduce one either. > > Consider users with always <= 2 windows per frame: If `display-buffer' > displays some temporary buffer in the other, reused window, shrinking it > to some few lines, calling `switch-to-buffer-other-window' in that > situation won't be of much fun. But that's an old issue. We could either prohibit shrinking, which apparently isn't an option, or restore saved height before displaying the new buffer (in `display-buffer-use-some-window', for example). Would that be the expected behavior? > >> > If someone wants `shrink-window-if-...' to have no effect only in > >> > `vc-diff', well, that's a different goal. > >> > >> But that's probably what some people want. > > > > I don't think we've seen a request exactly like that yet, but that would > > require a vc-prefixed variable. > > When we get such a request you'll take care of it ;-) Maybe. :) You'd have to notify me if I miss the bug. > > window.el (quit-window): Always restore window height when it's saved in > > quit-restore parameter. > > Installed as revision 108897. Works as expected. I believe this can be tagged as fixed now. --Dmitry From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 18 13:34:00 2012 Received: (at control) by debbugs.gnu.org; 18 Jul 2012 17:34:00 +0000 Received: from localhost ([127.0.0.1]:48831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrY8O-0002xj-51 for submit@debbugs.gnu.org; Wed, 18 Jul 2012 13:34:00 -0400 Received: from forward5.mail.yandex.net ([77.88.46.21]:50108) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SrY8M-0002xb-20 for control@debbugs.gnu.org; Wed, 18 Jul 2012 13:33:58 -0400 Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id 2129C120199A for ; Wed, 18 Jul 2012 21:27:50 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1342632470; bh=t18+wsZDwA54t9HsCO2TRWtE43DOSZSr/UgpmhCmfTQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=xCawEtyEcLBfmc2UeAMOtR/Aa3MWRpM7SmOTT3AUx2LABGerwTPJHflKX2GB3pRQJ E6XoHDRjpxQ+oCbqGGJ7j9/CLIZawRG23ShuZiFj4BvY5K0DIuRGQdKXpothgCpY4O B7XDGWFdD1XJ5MicxKSdofJemwnkM7KWtsInZo8o= Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id 0E8001BA0341 for ; Wed, 18 Jul 2012 21:27:50 +0400 (MSK) Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id RkJWrRwU-RkJWtHRp; Wed, 18 Jul 2012 21:27:46 +0400 X-Yandex-Rcpt-Suid: control@debbugs.gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1342632470; bh=t18+wsZDwA54t9HsCO2TRWtE43DOSZSr/UgpmhCmfTQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=JwYH3a5r8mGITXnDRM3rUBXQP2NtiJekhb7266J/VhnQzO/jhGdI+7P+0KFNxPdCx 3h9j8jDKifwJuHZdO6fkpvBf8Fl/tv+zfNlDfBfucWSq3Y1xSPpmZyt1zgH+ap81jv X5Q4ujVZwATdrSET8h8WcFPYHSjnss9GEoaQ12uU= Message-ID: <5006F213.2080807@yandex.ru> Date: Wed, 18 Jul 2012 21:27:47 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: control@debbugs.gnu.org Subject: #11810 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) close 11810 thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 26 08:36:56 2012 Received: (at 11810-done) by debbugs.gnu.org; 26 Jul 2012 12:36:56 +0000 Received: from localhost ([127.0.0.1]:40483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SuNJH-0002ax-PX for submit@debbugs.gnu.org; Thu, 26 Jul 2012 08:36:56 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:52660) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SuNJE-0002ao-CZ for 11810-done@debbugs.gnu.org; Thu, 26 Jul 2012 08:36:54 -0400 Received: (qmail invoked by alias); 26 Jul 2012 12:30:00 -0000 Received: from 62-47-63-27.adsl.highway.telekom.at (EHLO [62.47.63.27]) [62.47.63.27] by mail.gmx.net (mp037) with SMTP; 26 Jul 2012 14:30:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+tX7Fix9KtY6NmOUlwwYPY17T8PSr9G1CuMZP30x s7AaEMf9aPNxMg Message-ID: <50113845.9020908@gmx.at> Date: Thu, 26 Jul 2012 14:29:57 +0200 From: martin rudalics MIME-Version: 1.0 To: 11810-done@debbugs.gnu.org Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window 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> <4FF46B89.5040301@yandex.ru> <4FF56410.7000705@gmx.at> <4FF62109.6000608@yandex.ru> <4FF6876E.2050904@gmx.at> <4FF6D955.9010908@yandex.ru> In-Reply-To: <4FF6D955.9010908@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11810-done Cc: Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Installed as revision 108897. > > Works as expected. I believe this can be tagged as fixed now. Done. martin From unknown Mon Aug 18 02:37:01 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 24 Aug 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator