From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#36859: Customizable fit-window-to-buffer Date: Sat, 3 Aug 2019 09:57:48 +0200 Message-ID: <1d94d43d-45d8-c917-426f-f3ba8c0feabf@gmx.at> References: <87sgqnp9z8.fsf@mail.linkov.net> <6a42d2af-b17a-d2da-1c3c-655f3f2a356f@gmx.at> <87sgqmq67t.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="121856"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36859@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 03 09:59:31 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htows-000VYx-Vz for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2019 09:59:31 +0200 Original-Received: from localhost ([::1]:38864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htows-0003Gg-2Y for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2019 03:59:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37028) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htowR-000303-84 for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 03:59:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htowQ-0002R4-7v for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 03:59:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49450) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1htowQ-0002R0-3i for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 03:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1htowQ-0008S4-2C for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 03:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Aug 2019 07:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36859 X-GNU-PR-Package: emacs Original-Received: via spool by 36859-submit@debbugs.gnu.org id=B36859.156481908332399 (code B ref 36859); Sat, 03 Aug 2019 07:59:02 +0000 Original-Received: (at 36859) by debbugs.gnu.org; 3 Aug 2019 07:58:03 +0000 Original-Received: from localhost ([127.0.0.1]:58267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htovS-0008QV-Ts for submit@debbugs.gnu.org; Sat, 03 Aug 2019 03:58:03 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:49151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htovR-0008Q0-6f for 36859@debbugs.gnu.org; Sat, 03 Aug 2019 03:58:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1564819067; bh=aXT2mSMe+yb6S2pN83IDEMpS1BLQh7TLv8zJDZWBILg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=GG+JfC6k6b7YmCccqItPgh+l5bk0wJAKWUk990j1BlwY7lSNcaM9CRiWKSA57lsfs C81byCWayKzs6/BdaCAjmL5dfa0E+BY24P89MIvJYl957k4hiCwb5zu7vtqb+cy4fR wy/az8bz/FJzgfKLLRXz7w4ZcGV4xysI+9nEHTsE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([213.162.73.33]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWhRH-1hru0u2w6l-00Xtt3; Sat, 03 Aug 2019 09:57:47 +0200 In-Reply-To: <87sgqmq67t.fsf@mail.linkov.net> Content-Language: de-DE X-Provags-ID: V03:K1:n4bJ7fcsdSA3CRgl5SDhO4G/0srZSosmqUrkhuEK3JzkQOr1Suc GHKbPZOzyF6KbdLTWrJfZSUxXLp62emfEfRj+m4R8zzcxXwGthCz7PqB8+ZLirW4swSBaI6 6z4JnmlQKMfEpAaynhM+YMHv5ECtC5Px3di9RQKuN3IWtPXuwfHABzIh1mPO/mmIOgDLMvL W8v2v9J5oMUQ0JmXEGu2A== X-UI-Out-Filterresults: notjunk:1;V03:K0:AKz2WaRhcXI=:WKCDWLzykqWsGhY4ot3SDQ JnMQzTtus/RXryV4VN7XY5SZP9YstwwCAOfvbgINWIP1exrZDbtfwbdp+WjfmXGjJMgrIhoQB uylgIb9KlJeoatzEkLE2KVCQJvZMiMlOEJbvBACD+4Sz3aprjh6FDT51q7d76y2e77Y9XHwpB hqb7aLBnFbz9MmIWZRCRugehOJ1swh2kGbsfi4dBCDvOo8eGUrU1isXZjpGO6LxckmE/sI6z2 XKtZGw9P9SR7A9K8wWcc899VsIfgSlgr3WcEadb4S07JB+HqqUQgkXXgs/nwqtGWVp2uqvkRw ZAZOAw72K+ZFXAGHzalle4XR64MUZe7X4qE+8c5dJFOd4j0oxQ0jEyv+BQ5QmozFSyGTrUh/n 2BEEyzXqdTzzA6FbWUV+Eawf6iDKnzP1+KDGRjCOKRjJHBWphFspHbhjc6yNW2OTskXvcukc3 6QQ+gOtHjelNR0xVwGw+zHxErLllsfPvdyGDfKXTCMyM+EACvfUHc8Xo6XDefLIXREWvminra P0+n5hyKc2m0yot3Ob2NhK0nYhONgMTH0BNn1ZNGs3k4h99pLtCT6eDg+ECsoTOaR7LiCiY0m cgpUjEzaYSe8On6xO11KpGtBtyDYmZsriaTWimufqqGqq2sfeasUulTL52m3zxE2/o1slAtLC 6fCI3DH7wGbOQV9NcL+Nd4im7O8I+P46VrDNeAlCbvhsdmD4SMJuhKv24n5h4G7n6SxfPppnS CX9L3jhvHrcAd+r2691kBba/499u1D1pNvUWZ1K3qQZ0a0ZmvyZ4cCN8HnHOxB2XcETnJwqc X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:164420 Archived-At: >> What is a permanent window? > > A window that remains indefinitely after finishing the current command, > and where other buffers with different number of lines might appear. Then the "old windows" below ... > IIRC we only fit new windows or frames >> that go away when quit and carefully try to not resize other windows >> but the one used for splitting off the new window. Old windows are >> fit iff they did show the same buffer before and were created for that >> buffer. Such windows should, by concept, not be reused for showing >> another buffer. ... are such permanent windows that should not get resized by 'display-buffer'. > I see that the existing windows are resized with > 'shrink-window-if-larger-than-buffer'. So not only > 'fit-window-to-buffer' is involved. > > Two examples of 'shrink-window-if-larger-than-buffer': > - in vc-log-internal-common; This one should shrink only if the window is either new or has a 'quit-restore' parameter that passes the (and (eq (car quit-restore) 'same) (eq (nth 1 quit-restore) 'window))) test. In either case, it will ignore any user supplied 'window-height' option. > - in vc-diff-finish. This should probably do a similar thing. >>> I'm not asking to change the default behavior, but it should be customizable. >> >> In what sense? > > I hope it would be possible to specify a special action alist entry > in 'display-buffer-alist' , e.g. > > (window-height . no-fit-window) Wouldn't just (window-height) suffice? > to override > > (window-height . fit-window-to-buffer) > > This requires that more commands should use this alist in their > 'display-buffer' calls instead of directly calling > 'shrink-window-if-larger-than-buffer'. IIUC 'vc-log-internal-common' fills the buffer after popping to it so I cannot see a way to simply accommodate that. > Do you think this is feasible? If not, then maybe these commands > should provide post-display hooks such as e.g. 'proced-post-display-hook' > where 'fit-window-to-buffer' is added by default, but can be removed > by customization. We could introduce a new ALIST argument, say 'pre-display-function'. The function specified there would be called before running the body of 'window--display-buffer'. In the case at hand, that function would fill the buffer so OT1H 'shrink-window-if-larger-than-buffer' would know the real buffer size and OTOH a 'window-height' entry would allow to override that. I wouldn't know whether and how to suitably pass any arguments to such a function, though. martin