From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Sun, 01 Jul 2012 03:18:13 +0400 Message-ID: <4FEF8935.9010508@yandex.ru> References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341098324 7449 80.91.229.3 (30 Jun 2012 23:18:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2012 23:18:44 +0000 (UTC) Cc: Juanma Barranquero , Andreas Schwab , 11810@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 01 01:18:42 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sl6w5-00011s-QR for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Jul 2012 01:18:42 +0200 Original-Received: from localhost ([::1]:44062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sl6w5-0006zO-N1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jun 2012 19:18:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sl6w2-0006zI-WA for bug-gnu-emacs@gnu.org; Sat, 30 Jun 2012 19:18:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sl6w1-0000Pr-03 for bug-gnu-emacs@gnu.org; Sat, 30 Jun 2012 19:18:38 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sl6w0-0000Pm-LY for bug-gnu-emacs@gnu.org; Sat, 30 Jun 2012 19:18:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sl70H-0005s0-Sh for bug-gnu-emacs@gnu.org; Sat, 30 Jun 2012 19:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jun 2012 23:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11810 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11810-submit@debbugs.gnu.org id=B11810.134109856522540 (code B ref 11810); Sat, 30 Jun 2012 23:23:01 +0000 Original-Received: (at 11810) by debbugs.gnu.org; 30 Jun 2012 23:22:45 +0000 Original-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 Original-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 Original-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= Original-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) Original-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= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4FEEC259.7040308@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:61451 Archived-At: 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