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: Mon, 30 Jan 2023 17:43:35 +0100 Message-ID: <7732128c-540b-9e38-0bf3-26c2496d2c0f@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> 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="14542"; 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 Mon Jan 30 17:44:39 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 1pMXGl-0003Zu-7u for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Jan 2023 17:44:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMXFy-0004dm-JU; Mon, 30 Jan 2023 11:43:46 -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 1pMXFx-0004dV-6L for emacs-devel@gnu.org; Mon, 30 Jan 2023 11:43:45 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMXFv-00054E-9r; Mon, 30 Jan 2023 11:43:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1675097020; bh=CPP88OrozCG9IPAZwX+iqBcAxzgrVqqmPtIZsfTcQ28=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=NCEWlHccN6X35FJWetRCqzH0CzVBFzUTRm0Ih6/kDozRglA0nc3ZRgiHFLfofRCyq tjNML+Fleg0UbECxFEWXLQKHLnKUckf0+sH6UcH3UNUcRPtiIZVdAC5UHMowMBn6Sv p+Q1qzKXwvGXz7guaH2GzgCzS+MRvD+mx7qj791cuOrb6rsR0f8QUiNZ/dSVxFOx87 lON5i7JzX4s9ivnDw9NloXQilC1MX8Cuw7EfTOt9O+hYw90Jx3U4zZg1cosxaTZR1q 5KTSmuiXptHpbtBjfz4mT4AJFlWT4Tn58iDyaU8Q9LSGpAbGOEb/sHgYTZ2j+NN60I B3cD5MN0QBFTQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([213.142.96.157]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9dwd-1oYVab13Sf-015ZWR; Mon, 30 Jan 2023 17:43:40 +0100 Content-Language: en-US In-Reply-To: <835ycp6v48.fsf@gnu.org> X-Provags-ID: V03:K1:w4QYpH9HfamQJuPBCkK4ari4E8jmcKvgxqJlAC87UYwwTFjwpCE 3h9UtDq4soczKHu7SOixR0Nvnh6IZfsA8QNiVXHhiPJTVtq8HEAKvwYy9K23mfy9tKYojeQ RffOmkS2SsuTDq0gSVDw94cJrH69CbXdl9368yVXgLpUA8apVJbsyE1yUTgLazUp5ooru/X dCcGkyWfs8GTD098bWFmQ== UI-OutboundReport: notjunk:1;M01:P0:OW4DSGx8r54=;kobjCBlM1ej5YZF1U10sUa2tt3e GKHly0ND42dOVcbKvB7KPRC/CPSdrn10AS9QRoHaiT7Mk466DIdt0DpS6YADuMwpzCHR19ueR WGYXFDhPgslToL0H4FWx45Rk/ZA9pLEGXLqk/vu1zCTHwyiILSzYvnBesW6BsHbiMtsRiVGOU cKmmLnGRfqjLOlVzfccSs9oJz4OGK5xNq9g0tVtrDx7dmXvuucnizFIGeSBEAfmdO1jGahVxD aRyaADpAmSWpz42hP7H6xYnM05/voy35GXd1pZZd4e3WRVQ9yExie0iAlccMraA/QwQY8ksnP mcp7/aGo6YBQNKr8vZvrbHic/BsWLMy9R/KYc3u73ofYDok6G7YHNOUZGfF0OxtqvBzieuE45 x4SvNf5NGTA1n1J5p+2uH91iTUteupEIYe9lUGHhFAqF5rZv3XTi/l6KZ7moR5TH/gPt6z5ok mUWadnWFJOxHChClvJ5v1qwWVAwCCpgGrarjUf5txf5wSJuSzUUZf/brFe/J809fntmKt8HfF 8kxVEy9eZvSOVchYrA7vsgD4t+yBA/+HkpC0DSZEru5eP4nALKegWsZejBV9HDFsraxu+dyI+ p451DabztjmU2YqRBMbkr7kJSXDFHTfJsqeshj45AUIvT133ae0J+EfoW4c9+5OkFVmn+GdGS y2r2AKULBAz7omXQd9t15GEul3N7n4nTrlfljsZU6fo0e1lRwT+sohFFKH3QWgUrrX0xQaQpQ oLnvOi2V2RWl9vzZaCWMEGY2Y38ocK3jlJLGX2EPpLCrGuN7NiHC02bVhXU/faqoz4yX3DJW Received-SPF: pass client-ip=212.227.15.19; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:302794 Archived-At: >> I mean "any window used" by 'display-buffer' to display a buffer. > > Do you mean "every window used by display-buffer"? Yes. >> It would change the behavior iff a user or caller had added a non-nil >> 'bump-time-stamp' entry to the alist. > > And who will add that entry? IOW, how would this feature work, with > the patch you proposed? Just as with any other action alist entry as listed in section 29.15.3 of the Elisp manual. The example I gave shows what an application can do to get the behavior wanted in Bug#45688. If someone comes up with another example, I can try to tell how to solve that. >> But to return to your question "Would it work to just temporarily select >> the window inside display-buffer-use-least-recent-window, so that its >> use time is bumped without any sneaky primitives?". The XEmacs solution >> cited above does precisely that and that's why I posted it here. > > So we could make a change in display-buffer-use-least-recent-window to > temporarily select the window, and then there would be no reason for > us to artificially bump the window's use-time via window-bump-use-time? You would still "artificially bump the window's use time". Just that you would also make its buffer current, swap in its local variables, mark windows for redisplay, maybe select another frame, move minibuffers onto that frame, resize the minibuffer window ... And then repeat all that in order to reselect the previously selected window. And at the very end blame the WM when it raised a frame where all we wanted to do was to change the use time of one of our windows. Emacs with a separate minibuffer frame is broken here for almost a year because someone does "temporarily select the window" and because 'select-window' now behaves in a way it never did. I know that I'm fighting against windmills here. 'select-window' is too heavyweight. It should be reserved for the user to choose another window to work in. >> Why you would call a primitive like 'window-bump-use-time' "sneaky" is >> beyond my comprehension. > > Because it pretends a window was selected whereas it wasn't, and > because it causes issues that you yourself pointed out And having 'display-buffer' select a window for the sole purpose to bump its use time would not pretend anything? > (and which now > require changes to bump the use-time of the selected window as well)? You would have to do that also when you explicitly select the window. > I'm not sure I understand: is this instead of > display-buffer-use-least-recent-window, or in addition to it? It would be a lightweight alternative. > IOW, > how do you recommend we fix the issues that > display-buffer-use-least-recent-window introduced, which you mentioned > in your previous messages? AFAICT Tom is trying to fix them. > Also, with the fixes you propose, would there still be need in the > changes proposed by Tom, and if so, why? It sounds like he is trying > to fix problems which your patches fix in a different way? 'display-buffer-use-least-recent-window' is here since Emacs 28 so I think that Tom's changes are needed. What Tom is proposing is to have 'display-buffer-use-least-recent-window' encompass the behaviors of 'display-buffer-reuse-window' and 'display-buffer-pop-up-window' in order to bump use times in these cases too. My patch bumps use times for every buffer display action once a 'bump-use-time' entry has been added. > Bottom line: I'm struggling to understand what is TRT to be done about > these issues, first and foremost for Emacs 29 (since > display-buffer-use-least-recent-window is new in Emacs 29). Would you > please help me figure that out? 'display-buffer-use-least-recent-window' is not new in Emacs 29. Let's wait for Tom to work out a fix for that. martin