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.devel Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames Date: Wed, 1 Feb 2023 19:33:19 +0100 Message-ID: <5d9d2bc5-3e2a-b4fd-413f-4595a3d8a1e3@gmx.at> References: <834jsccepb.fsf@gnu.org> <83sffuap62.fsf@gnu.org> <83a622abpz.fsf@gnu.org> <8af34023-d3d7-a18d-54c5-f418515dea1c@gmx.at> <835ycp6v48.fsf@gnu.org> <7732128c-540b-9e38-0bf3-26c2496d2c0f@gmx.at> <83cz6v53e1.fsf@gnu.org> <9c7209b0-2af2-ab16-7b04-397d7d069025@gmx.at> <83357r5269.fsf@gnu.org> <83a61y3irr.fsf@gnu.org> <84c98406-5aea-de0e-67bb-10fffd5dd5ad@gmx.at> <83lelhz3o9.fsf@gnu.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="32137"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tgbugs@gmail.com, emacs-devel@gnu.org, larsi@gnus.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 19:33:36 2023 Return-path: Envelope-to: ged-emacs-devel@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 1pNHvM-0008Dm-7Z for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 19:33:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNHvE-0002zj-87; Wed, 01 Feb 2023 13:33:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNHvB-0002yx-12 for emacs-devel@gnu.org; Wed, 01 Feb 2023 13:33:25 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNHv9-0007i1-9O; Wed, 01 Feb 2023 13:33:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1675276400; bh=tNnDXNN+TZbfDiHkrEQXIaDTSIEA2nEPL29jKnXG9Jc=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=q5rwpAfX+/ZJ5MgtcitPnrpzP93tvEv2usDKRxzAEpfy4CztUMkft/DAqxTI/PEGo +ioCZcPEQsPWT7/fggG1LD0/OFDXuUdlBnIVT5yWzohOEyURwGkfiLV6sk6NTcgGr8 /vjiv9NZ8BumycUZ96ZKJzm+HUxRUYXVPfQ5ZUm0B1A2ivMfsEFrZ11VxYlo6TwPNx 79t3foIsjOlpJeMLbrLgMWic4rHlwFQhxgZnFPBcQJBZ80l4nvEeECSrxJwBDc4Fe0 Hv7XNS4fyh4hVfQDY1aAXZ+Cre5q/Lq3XZsCsIErp76ltFK+UfrRESU0Bcx/IwJbpb a53s1x0QDy8sw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([213.142.97.245]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mg6dy-1ohtxW292E-00hbC2; Wed, 01 Feb 2023 19:33:20 +0100 Content-Language: en-US In-Reply-To: <83lelhz3o9.fsf@gnu.org> X-Provags-ID: V03:K1:bINfO8slXi36xwHtmoICXwGSllu0sYXuu4cQ5rD1ee2OH+Z2s71 dlajiECW0elGsPw8KfQTPfeD4BeNTXU5lnkqKFngBc9dG96YL4Q5VhjN85piym4GWXrhwMx f0XbiQbAuaoF7WHqLkfLGMdHNPeWTsqA024lQAOoiK49cdO/aqtJMkDK1ct9a0UY91dxYAT seDasxV70TIm0JzmDbJEg== UI-OutboundReport: notjunk:1;M01:P0:/+1Aci6Ri2I=;O6m4F+GHU/svfwtMaCOCSB10XI5 JfSbsJ+BJjz8QUbCXPgUy4JfENQ3ZpjEbXEaVlsffV5SciK4MVZldnr2sRTfHnWxMkKU40YjD aPMuNKT4gPXLmL1xdglt+BCS0+gfDx3mPHxkM+jvwv+dn5OzgBmSTuN+IfenqSzVcCmWt3LuN O3rbMmb5FjWb5j3ePbI1u2gdRfmzud7/0OZ2fMzhFPQFdBxOFlnAz60aiizu37PvEVgFVnyDV 0pnsyayAlUPngDOcV5u8xW0mm8bzNUh0jjn8e+GYCN5/7n+Knwhiav5C27+ZWWDTTykxIXDks BryAom62J7jb41KLuW9AzxzkwLYWcTvGh96pJ3BnAeHzkdvrYlV11uXFZESTIrfWaTKkkyilH /1K1ZPkJgg3fZxyyFdncDj6GbkEb7LshnKl9sPTHmGYk5BHiobtW/m49ObjJLULDyVM2DK6Wi lqdqyJyu60AUut7VYPp8IlT2nHeeGnrH65JvGs2t/Oh/yXa/wGEWdnsgYbKDhVoiZ9wG5kFPT 7OBsrbqjHk3cY4fy/tcjmFiWuPEhOgnJ+KWZuLOW6cw4CD6Vsb601IzhPlPZhQvNfs7jD9N/B gxGgEIQRwgSF3BhthVZu1QhfmI4mX5tPP5iwasG2Es7pECdIBiByF69ZpzrsPwqtBLB6akE5/ Yh4L8+g0dTIyVfeeYA1s68wOHt1hrneReho1122YO9SRdJO7ToWHCbD9+eiFIKXBYOgHR4XEq 7tbECKaMzNYXfFfihVGKl05nNXCDdb2K2mU/7XA3h2h/bk4ibCSINFyQHOJ60SV5ka+eN/iT Received-SPF: pass client-ip=212.227.17.21; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302873 Archived-At: > Is this related to display-buffer-use-least-recent-window and/or > window-bump-use-time? Or is this another set of issues? It's another set of issues loosely related to 'display-buffer-use-least-recent-window'. I found it because I tried to understand why that function did not always return the LRU window. See my other mail to Tom. > Would it be possible to modify the effect of > display-buffer-avoid-small-windows so that it works via the > window-min-height alist entry? No. 'window-min-height' so far is honored only in functions of the 'display-buffer-in-direction' type because there it's easy to tell which window should have that property. It's not used in 'get-lru-window' because that function is not used for buffer display alone. As a rule, buffer display options should never show up in functions that can be used in another context. We could give 'get-lru-window' an additional ALIST argument which would indicate that it was indirectly called by 'display-buffer'. I wouldn't like it and I don't think we would be able to figure out all the consequences in due time. So we need a 'get-lru-window' clone that can be used by buffer display and takes only an ALIST as argument and nothing else. 'display-buffer-avoid-small-windows' is an attempt to reintroduce a concept we tried to abandon many years ago. It's inherently like 'pop-up-windows' where applications and users fought each other by setting or binding that variable to their like with undefined outcome. We tried to stop such fighting by giving users options like 'display-buffer-alist' and 'display-buffer-base-action' and giving applications the ACTION argument with clear precedence rules. There's no precedence rule for 'display-buffer-avoid-small-windows'. martin