From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#45688: 28.0.50; New action for display-buffer? Date: Wed, 20 Jan 2021 09:08:56 +0100 Message-ID: References: <87im8a1dff.fsf@gnus.org> <83y2h6133r.fsf@gnu.org> <8735ze0yp7.fsf@gnus.org> <83o8i20w1f.fsf@gnu.org> <87lfd5yny9.fsf@gnus.org> <87o8i03gem.fsf@gnus.org> <528b7d6b-403a-ffef-b0a0-4a0b6d92bec8@gmx.at> <87turpvxv0.fsf@gnus.org> <87turnh6u8.fsf@gnus.org> <87im83cn02.fsf@gnus.org> <568151d0-c8fd-1643-56a7-87ff36ce234d@gmx.at> <878s8psj2l.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5946"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45688@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 20 09:10:12 2021 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 1l28ZA-0001SU-DF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jan 2021 09:10:12 +0100 Original-Received: from localhost ([::1]:34102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l28Z9-0004OG-Cl for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jan 2021 03:10:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l28Z0-0004NW-KD for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 03:10:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l28Z0-0001xj-CB for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 03:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l28Z0-0006zp-6w for bug-gnu-emacs@gnu.org; Wed, 20 Jan 2021 03:10:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Jan 2021 08:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45688 X-GNU-PR-Package: emacs Original-Received: via spool by 45688-submit@debbugs.gnu.org id=B45688.161113014926818 (code B ref 45688); Wed, 20 Jan 2021 08:10:02 +0000 Original-Received: (at 45688) by debbugs.gnu.org; 20 Jan 2021 08:09:09 +0000 Original-Received: from localhost ([127.0.0.1]:52707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l28Y8-0006yU-LV for submit@debbugs.gnu.org; Wed, 20 Jan 2021 03:09:08 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:45447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l28Y4-0006xx-Ql for 45688@debbugs.gnu.org; Wed, 20 Jan 2021 03:09:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1611130138; bh=ceoMwbJs56AnhGDtcW9D8NepdYD92h/xjWswj0T08L0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=LBffdwZgRC5kkQQ+3pO30lVfA/5DnxoP2EJnoMBP11dvbArfbqBqCc6Jxlsk1/42m GtYO+gmcZ/I2kINf+eVjgy66YLIViksU9htSodIIMn6O4mhOR9sPkwhqj5PE57tCnO OSbVb7CxiN/uW/MxrQuEKj82U4TuwFOJvykx8wvY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.39]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N49h5-1m1DWl1W5p-0103uD; Wed, 20 Jan 2021 09:08:58 +0100 In-Reply-To: <878s8psj2l.fsf@gnus.org> Content-Language: en-US X-Provags-ID: V03:K1:czJEh6H/T13oEe3jEf6Ud96aSuFOnxRgxf9yNshKHQAr1TfpDAN V1Heu9w0JAEZBifl0RkyqfLwz0j5+5XHMi8cMDqAZZiLYHdHkSUkU9jXUlYASqvIclIP5VN wN7njhblW7vmXd0NZDgnEwYzY2jePsRaZi2my35IUTizmL7gvfxqgqEelx4hp55nMHAD5UK 5vld3lZoGQQkle8j2vIzg== X-UI-Out-Filterresults: notjunk:1;V03:K0:ioAK7Df5YoY=:HCfUT02rmi8mH+L54fp+T0 tFMheekOy+Zp+Cyn8QoVz/W/sNZ8zXo6ugzw1MvHAL9bpr7+M0nq7hqeOv0/MtJVzNdBCXGV4 IEt3jJFTf1R8XkfyeXSj4nSNGiy2nx8SqdPh8zXz7GhvNRZRJCCHUcQExmtZuo0I08Zl5YTV7 TUv2pB+KJTya+JPCulIb8BKFcVh/iKl8zbLSttUUV5eAspomhNMu8+H6uQhkx8SNe/kEXcZJP 0LsB7IFlial94BCOyHVsDPHB3Uhx3uUXMotwaJFtC4IiGrKr0OL0CYROrsSyV4NjMo4nE0xQw b5DI9qUMk0I1HPcYlbrr346kDC7VMszETrI2ET2bIid9EDhaEI7wttDRhBuYld4ByQl7uKVWO FLExxdHuBvHIgtHm3igz65RHWoDg3trNF95a3CairXwhFSzdxnFyYMHaa8p32g8+mJCxty6V7 3DpJ6yrwjuc+/AwFA0T4HNA2luUiCdgvG/ip1fWZTWTTozl81wJ2ss3tOZNIWRskzRB2pKkFi R/009F2FG9qol8zyMDCi4s6/uq0fVA4yJ1BPdwkEFozO09N8yPuGW7jQAQWKiufYYOkwV9GyU q/zT0fa+UwRAXfeBS9aOS7YVfjspnpixCD5rlLBHcIM5S5t+bfGA7kPua0H/cv4yM4zc8rljA bNvjPM6LXPdGrj4jjkJVXeO1GiXhpXlSayj7hbNF3kfIlgKLS+Ff44ZG0vdDt6bkBalFHg0pp J5S1jNmqYrz8DLHBveQ1cbIxjt0QKW6+T+r7R4MRzY6NA5FO38UE+HGXILzTqnJQsuzYVQp2 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:198253 Archived-At: > Well, it's certainly the most common one, but having more than two > windows in a frame isn't unheard of, either. Right. But how reconcile the two approaches? > I think that makes sense... if you have that mode enabled. But if > you're not asking Emacs to resize windows in this way, then having > `display-buffer' resizing windows is somewhat confusing. The one you cited earlier certainly is. The basic idea is that a window that was good for 'display-buffer' once, should be good again. Unless it shrunk in between. >>> In related news, get-lru-window doesn't seem to work reliably? I don't >>> have a reproducer for that, either, but it seems to happen if I have a >>> three window frame, and I call: >>> >>> (setq lru (get-lru-window (selected-frame) nil t)) >>> (window-bump-use-time lru) >>> (get-lru-window (selected-frame) nil t) >>> >>> will then return the same window as `lru'... >> >> How do you "call"? I suppose there's no chance to make another window >> but the selected one the mru one. We would have to look into the inner >> workings of that "call". > > eval the expressions. Where and how? If you do that in the minibuffer window alone, you should get a result not affected by 'select-window'. Otherwise, all bets are off. martin