From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#39822: 27.0.90; Cannot set *Completions* buffer height using display-buffer-alist Date: Fri, 13 Mar 2020 10:38:26 +0100 Message-ID: References: <87k146q02n.fsf@firemail.cc> <87ftet76tv.fsf@firemail.cc> <21d2102d-367b-54da-33c5-1ae1ac579bd9@gmx.at> <87imjpw3wx.fsf@mail.linkov.net> <87o8tfzmrx.fsf@mail.linkov.net> <43297d89-9e87-0b23-0bca-98b13a27cfe6@gmx.at> <87ftep2h1x.fsf@mail.linkov.net> <87pndrpt8t.fsf@mail.linkov.net> <87o8tawf59.fsf@mail.linkov.net> <1a051c61-8522-1932-8600-e220f19105df@gmx.at> <87pndhjiac.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127921"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Davor Rotim , 39822@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 13 10:39:36 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jCgn1-000X94-CQ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 10:39:35 +0100 Original-Received: from localhost ([::1]:56116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCgn0-0002Re-3B for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Mar 2020 05:39:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53187) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jCgmV-0002RY-KC for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:39:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jCgmU-00036I-Je for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52181) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jCgmU-00034w-CH for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jCgmU-0003Gq-A9 for bug-gnu-emacs@gnu.org; Fri, 13 Mar 2020 05:39: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: Fri, 13 Mar 2020 09:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39822 X-GNU-PR-Package: emacs Original-Received: via spool by 39822-submit@debbugs.gnu.org id=B39822.158409232212545 (code B ref 39822); Fri, 13 Mar 2020 09:39:02 +0000 Original-Received: (at 39822) by debbugs.gnu.org; 13 Mar 2020 09:38:42 +0000 Original-Received: from localhost ([127.0.0.1]:58154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCgmA-0003GH-6E for submit@debbugs.gnu.org; Fri, 13 Mar 2020 05:38:42 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:46343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jCgm8-0003G4-3k for 39822@debbugs.gnu.org; Fri, 13 Mar 2020 05:38:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584092309; bh=Dk7b+ZKQF7gCU7VdrddnUYBm3o5OQ+AvJImvPjhhQL0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=W3DK3M7lzWEGxZHK7dgfkJ0H3B5jhQMBztOVdJ+US2BhIWBjy9f/t3k6pJmOrRw24 VKVQYXv1MFogJOvC0C80zp6QD9Tqeoo3QFpuntijaI/8AY7gOZW7FOmiVSqRoMKdWd SavZ8StcY8Za5fAmxr7ffi/k+Cqs9CtgItQ7qUHE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.120]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N6KUT-1jNVb33Qdt-016k3R; Fri, 13 Mar 2020 10:38:28 +0100 In-Reply-To: <87pndhjiac.fsf@mail.linkov.net> Content-Language: en-US X-Provags-ID: V03:K1:s2cwkj1+5E8WGmwkKfigvi7dcZATpb/cc0RgLk710XuqTreWjIG cbtYymPJKAj8twUDXlH92NIOLkj4wtOMJmJv4Ze56itjdK/oiruXaRe0k/0ZF7w/NR8i7Gr bHpiDd2/M7re2XCY0EVj4wvhSRQvkzmzS694Fbh+YPR/QZZT0OzUCv96oSv4eAIduK5OrRj jrFuMhCr7Rh2k1TancBtw== X-UI-Out-Filterresults: notjunk:1;V03:K0:VycPhwqKTmc=:yVFvWeyQqPRRP3IPUXdr0k ylt5seJ9hlAygMUprzeyRNvtP6ExlGAZnwNcn1RlkwXy6w68rIY6A/j7K5Yp4ubk90owQ+6x8 D2kuZfvyrzHwAIjo33mnGUFehWJ4d77vwgxvTgfcCXAa3WMj9rQ7cO44bqM+/LWw3l7/9GvVo vnTJZrOq26WYGGJS4aaTa1/tyA8CdkojMxTwcQyLvl4+F4/sLUgFJoaZzUzGQSJxPx9DZwCbu +HjUcU5NarbzeKmg4QJcu1/ECupuQCtH4AIltxpoaNMYx6iWkIgi3MPjuzx5V5Rd0RG1AHXhu rXRDEBAKBJ0mvM621V5vOMoaTthpPqWI3h3O1NC9xQ++68CGOy26GmjgI2PrKQo7MCgFc+OP9 xhTK4bmy4TUt4LICjr8zNMnEixU0w7C836T1vrAyFFUf4GzGP2i3WN55Wu5LjPfDIZrBoMHPe wbI0IZFIiHQUIgTmPDv6H9ON8OFFVoSrozCUfCjPoP8LDBsmrXFhD9AJUu1GoSddkuA7QOnrE Z7m+Ip/naio76cTJ3MBMGd8/PvKhGq6jT7CwABAaxHeEWYULCXUdnk2vHAOZUjaQo2/Halc7V Kucz1lbe7kLfMlKdXWsuIJvA42IVxho+d6/ltCVAiqoK1z6Ad433oActcp4PHdbfENyrsa8Np D4SBFlfZ2RD1kha6Mf6Jc39BAdIjNIfwsgLN7H7pdFnMS9KDPyhIkLLhtNb++328BSbPFEmvR iqvt1QX/hTjS9dQ2sSNnnCIoE1W2goqVhBdLR8r/1jlhIpJRkcG4oXvIeR/G04a/3DqKCxPy 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:177258 Archived-At: > Here is the first step, this patch seems to keep the original behavior, > but I need your help to finish it. Could you confirm that calls of > window-preserve-size at the end of with-displayed-buffer-window are > not needed anymore after this patch is applied, because there are the > same calls of window-preserve-size at the end of window--display-buffer > that are called later after buffer contents is filled > by after-display-function in the middle of window--display-buffer: Didn't we agree that 'vaction' is harmful anyway so these "same calls" should never have been applied in the first place? I wouldn't bother about them at the moment, when something fails we find out soon enough. But what if a function like 'dired-format-columns-of-files' wanted to (1) know the width of the window used for displaying the buffer, (2) according to that (presumably fixed) width adjust columns, establish a maximum width of buffer lines or do something else width related, (3) leave it to 'window--display-buffer' to adjust the window height afterwards? And be able to do (1)-(3) in the orthogonal direction, that is, base (2) on a presumably fixed window height? I conjecture that in such case, the function (functions?) specified by 'after-display-function' should be supplied the window to display the buffer as first argument (just in case there's another window showing the same buffer). WDYT? martin