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: Sun, 29 Jan 2023 18:39:36 +0100 Message-ID: <8af34023-d3d7-a18d-54c5-f418515dea1c@gmx.at> References: <834jsccepb.fsf@gnu.org> <83sffuap62.fsf@gnu.org> <83a622abpz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------w2gYLooGc130SFmWCs0zkj84" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10048"; 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 Sun Jan 29 18:40:22 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 1pMBfC-0002Tj-KM for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Jan 2023 18:40:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMBed-0001Zg-Nr; Sun, 29 Jan 2023 12:39:47 -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 1pMBec-0001ZH-Ee for emacs-devel@gnu.org; Sun, 29 Jan 2023 12:39:46 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMBeZ-0007N9-JH; Sun, 29 Jan 2023 12:39:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1675013979; bh=Q7XaCziQpcUIEOEo49pMU4iF7MMhF0HV4qhhXYbc2QI=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=Z9dTpbWCV/cnSKVyGPwqfolXd3F3IML4eNO2dDZna7r94czEK/9swWzl7RMr0mea8 TRNXqLYT2bnRpBenn4s7o7GC2hnk5TB1qnwXxysNpZ4V93vlrx/G59uTJ3P+B2v26t qp4ASA3LGhRsM16jz2BnP9YXkt9tO3s5zOxEnryQ1UZl5HtLG6Jqlb404yFimEZ+sF bJGbqsviovTJFOQwUwXrHlEMfXYo0lWGrLZYLsAqXCd9iPY2mL12H/EjXPk7iMruAf ctUH7LjDUkeeZTNoTmphAQCjB08G2VFBkWxZjWEKNTxZ/P3P5kyqSYdFHyi8QL0mWc MvDJ4ktlXgUfg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([46.125.249.76]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4JqV-1pMSdP2Hqr-000MEq; Sun, 29 Jan 2023 18:39:38 +0100 Content-Language: en-US In-Reply-To: <83a622abpz.fsf@gnu.org> X-Provags-ID: V03:K1:f3TTY71AktVy2ECdZIp/jpzqmBWHly45kxbivYeCSY46e4skuK0 7CeBTVwXGvqLYORb9zNyTa4grRlntTTS9FVV+l3T9BHBx+ukMvL7tI1GX3wKKc8jKqszru3 IOAdoAzBVpqpXf6YgjcVlrPv/o3fJI3Tl0G5QBG697mE8fmIDLYwblyvTNdvkkjQ4D0YiiH Fh5rp/nqgObwP2lYRTUog== UI-OutboundReport: notjunk:1;M01:P0:yaD2IG0LnZA=;zL3J778leq22Et7m6njGvjcU04v FvoW9SJB72kuVp/e12hZ0z+iW6XyLcrNABk/xH/ZC68AfkrdmrSKdIDwP1Djp5D7Se5L3zRyw 9JEBDct2TW4DHD58WTIRbTTZUlqkAR0SHb4IYwkg8ixcjca9Bub2rsLvXdmZBGDJZ57LxdKtB Pgs63asThTZUfJMCEE8Wjdnx8QsWcCduWpdOsn5Elk8QTzGNHYGHwcbBoMAVLqj5E+CZlKd1S EIAsgrEVE/wR5PjImCN7q7HgmbqmS8sDPS4uy14suVyxT24UIlbLT4rhIPE5AsWoo/dTDHiqh eiQs+1FWbW9axpG4KgiArNEmxZKwj9E91QJUoFpzCQOn6nm1htmnK1nWKkdbSbogkxsnV2Yfs 7Y3Hyue+qkIwdZBDip9Ae4+Bt7X1MgoS96QDTL6sOV6SC598WVYG5ODKlp9MlAvSr9QcAorXb KAVBJTz9Pzf4PiHHexZdfhn/WjgXNd2WbIKFDqGd4J7N8hlMFPHchBGV45ijsRoFWe7ZtDNug OvpAoQNvME3yxeLqnqBMpw48UbXREDztZ3P1ANQ0Fky+sRFpTxoO2lSWXQLD41mpA0mLetmw+ bp+tniCiiKlGmqlwP8hkBEQdOYvY9aDRcr3ec0uaz1VUHrm0Z7pFwJi/q8N43XCzU7V79GLau pNSAFWZ5wCqXDM/pNRoMinO7UPfN/aYLoa712gNEw8h8bhqLHQrK4hbdkOEeRAkjTk4Hw+9yr YpoOFIEE7FUlbjBieJwx60hHq6j3vB7vw+qiRfjjM3Ddj9Q/PY+3aRB83dh3sTkpkcYa45sE Received-SPF: pass client-ip=212.227.15.18; 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:302750 Archived-At: This is a multi-part message in MIME format. --------------w2gYLooGc130SFmWCs0zkj84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit >> We need a way to bump the time stamp of _any_ window used. > > Sorry, I don't understand what that means in practice. Specifically, > what do you mean by "any window used"? used by whom and under what > circumstances? or do you mean any window that is currently displayed > on all the frames? I mean "any window used" by 'display-buffer' to display a buffer. >> Otherwise, >> the various action functions will continue to fight each other. Lars >> wanted to go the way XEmacs did but stopped in the middle. And XEmacs >> uses >> >> (if (window-buffer window) >> (save-excursion >> (save-selected-window >> (select-window window) >> (record-buffer (window-buffer window))))) >> >> to bump the use time of every window used by 'display-buffer'. > > You mean, do this every time display-buffer is called and selects some > window? But that would change our behavior for all the callers of > display-buffer, whose names is a legion. Whereas the intent was to > provide an optional feature that hopefully doesn't affect any existing > behaviors. It would change the behavior iff a user or caller had added a non-nil 'bump-time-stamp' entry to the alist. Existing behaviors would not be affected. I'll give you an example. Apply the attached bump-use-time.diff. Now with emacs -Q evaluate: (let* ((window-combination-resize t)) (split-window) (split-window) (display-buffer (get-buffer-create "*foo*")) (display-buffer (get-buffer-create "*bar*"))) *foo* is nowhere displayed because 'display-buffer' displayed *bar* in the least recently used window instead. This is the behavior Lars wanted to avoid. Now instead do (let* ((window-combination-resize t)) (split-window) (split-window) (display-buffer (get-buffer-create "*foo*") '(nil (bump-use-time . t))) (display-buffer (get-buffer-create "*bar*") '(nil (bump-use-time . t)))) This is the behavior Lars wanted. Look, no separate action function needed at all. If anyone has a solution to that problem that's simpler than this two-liner, I'll be all ears. >> > 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? Then we could remove >> > window-bump-use-time. >> >> As Lars conceived it, independent 'display-buffer' calls should be able >> to build on previous ones. Otherwise, we could write a function like >> 'display-many-buffers-at-once', within that function mark all windows >> used as temporarily dedicated to their buffers, and at the end restore >> the previous dedicated states of these windows. Obviously, a function >> like 'display-many-buffers-at-once' would not qualify as buffer display >> action function. > > What do you mean by "independent calls"? Or what are "dependent > calls" for this purpose? Without understanding that, I cannot see how > what you wrote here answers my question, sorry. A dependent call would be one inside a function like 'display-many-buffers-at-once' where you want to avoid that the same window is used for displaying first one and then another buffer. Any other calls would be independent. 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. Why you would call a primitive like 'window-bump-use-time' "sneaky" is beyond my comprehension. Is it because I originally proposed it? martin --------------w2gYLooGc130SFmWCs0zkj84 Content-Type: text/x-patch; charset=UTF-8; name="bump-use-time.diff" Content-Disposition: attachment; filename="bump-use-time.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3Avd2luZG93LmVsIGIvbGlzcC93aW5kb3cuZWwKaW5kZXggN2Q4 ZWU0ODYzNS4uZWY0NWY2MjljNSAxMDA2NDQKLS0tIGEvbGlzcC93aW5kb3cuZWwKKysrIGIv bGlzcC93aW5kb3cuZWwKQEAgLTcyNzYsNiArNzI3NiwxMCBAQCB3aW5kb3ctLWRpc3BsYXkt YnVmZmVyCiAgICAgICA7OyBVbmxlc3MgV0lORE9XIGFscmVhZHkgc2hvd3MgQlVGRkVSIHJl c2V0IGl0cyBkZWRpY2F0ZWQgZmxhZy4KICAgICAgIChzZXQtd2luZG93LWRlZGljYXRlZC1w IHdpbmRvdyBuaWwpCiAgICAgICAoc2V0LXdpbmRvdy1idWZmZXIgd2luZG93IGJ1ZmZlcikp CisgICAgKHdoZW4gKGFzc3EgJ2J1bXAtdXNlLXRpbWUgYWxpc3QpCisgICAgICA7OyBCdW1w IFdJTkRPVydzIHVzZSB0aW1lIHNvICdnZXQtbHJ1LXdpbmRvdycgd2lsbCB0cnkgdG8gYXZv aWQKKyAgICAgIDs7IGl0LgorICAgICAgKHdpbmRvdy1idW1wLXVzZS10aW1lIHdpbmRvdykp CiAgICAgKGxldCAoKGFsaXN0LWRlZGljYXRlZCAoYXNzcSAnZGVkaWNhdGVkIGFsaXN0KSkp CiAgICAgICA7OyBNYXliZSBkZWRpY2F0ZSBXSU5ET1cgdG8gQlVGRkVSIGlmIGFza2VkIGZv ci4KICAgICAgIChjb25kCmRpZmYgLS1naXQgYS9zcmMvd2luZG93LmMgYi9zcmMvd2luZG93 LmMKaW5kZXggOTBmYTZhYzJkZi4uYTIwYWM3MGNiZiAxMDA2NDQKLS0tIGEvc3JjL3dpbmRv dy5jCisrKyBiL3NyYy93aW5kb3cuYwpAQCAtNzczLDEzICs3NzMsMTggQEAgREVGVU4gKCJ3 aW5kb3ctdXNlLXRpbWUiLCBGd2luZG93X3VzZV90aW1lLCBTd2luZG93X3VzZV90aW1lLCAw LCAxLCAwLAogCiBERUZVTiAoIndpbmRvdy1idW1wLXVzZS10aW1lIiwgRndpbmRvd19idW1w X3VzZV90aW1lLAogICAgICAgIFN3aW5kb3dfYnVtcF91c2VfdGltZSwgMCwgMSwgMCwKLSAg ICAgICBkb2M6IC8qIE1hcmsgV0lORE9XIGFzIGhhdmluZyBiZWVuIG1vc3QgcmVjZW50bHkg dXNlZC4KKyAgICAgICBkb2M6IC8qIE1hcmsgV0lORE9XIGFzIG1vc3QgcmVjZW50bHkgdXNl ZCBhZnRlciB0aGUgc2VsZWN0ZWQgd2luZG93LgogV0lORE9XIG11c3QgYmUgYSBsaXZlIHdp bmRvdyBhbmQgZGVmYXVsdHMgdG8gdGhlIHNlbGVjdGVkIG9uZS4gICovKQogICAoTGlzcF9P YmplY3Qgd2luZG93KQogewogICBzdHJ1Y3Qgd2luZG93ICp3ID0gZGVjb2RlX2xpdmVfd2lu ZG93ICh3aW5kb3cpOworICBzdHJ1Y3Qgd2luZG93ICpzdyA9IFhXSU5ET1cgKHNlbGVjdGVk X3dpbmRvdyk7CiAKLSAgdy0+dXNlX3RpbWUgPSArK3dpbmRvd19zZWxlY3RfY291bnQ7Cisg IGlmICh3ICE9IHN3KQorICAgIHsKKyAgICAgIHctPnVzZV90aW1lID0gKyt3aW5kb3dfc2Vs ZWN0X2NvdW50OworICAgICAgc3ctPnVzZV90aW1lID0gKyt3aW5kb3dfc2VsZWN0X2NvdW50 OworICAgIH0KIAogICByZXR1cm4gUW5pbDsKIH0K --------------w2gYLooGc130SFmWCs0zkj84--