From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window Date: Tue, 03 Jul 2012 00:39:17 +0400 Message-ID: <4FF206F5.4030101@yandex.ru> References: <4FECAF0F.1080307@yandex.ru> <4FED556A.4060702@gmx.at> <4FEE2EA5.5060905@yandex.ru> <4FEEC259.7040308@gmx.at> <4FEF8935.9010508@yandex.ru> <4FF012FE.1010502@gmx.at> <4FF05DC0.4080609@yandex.ru> <4FF146F4.1080103@gmx.at> <4FF1A30F.4090806@yandex.ru> <4FF1CD2C.5000704@gmx.at> 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 1341261592 25736 80.91.229.3 (2 Jul 2012 20:39:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2012 20:39:52 +0000 (UTC) Cc: 11810@debbugs.gnu.org, emacs-devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 02 22:39:48 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SlnPP-0008Ds-3f for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 22:39:47 +0200 Original-Received: from localhost ([::1]:51583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlnPO-000878-5h for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2012 16:39:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlnPK-00085z-QV for emacs-devel@gnu.org; Mon, 02 Jul 2012 16:39:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlnPI-0002XW-Nw for emacs-devel@gnu.org; Mon, 02 Jul 2012 16:39:42 -0400 Original-Received: from forward13.mail.yandex.net ([95.108.130.120]:59109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlnPI-0002X2-4f for emacs-devel@gnu.org; Mon, 02 Jul 2012 16:39:40 -0400 Original-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= Original-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) Original-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= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4FF1CD2C.5000704@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 95.108.130.120 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151377 Archived-At: 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.