From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69093: window-state-put doesn't update current buffer Date: Fri, 16 Feb 2024 10:39:36 +0100 Message-ID: <9bc224fd-265b-42a6-9315-9e1caa9e7172@gmx.at> References: <86il2s6cva.fsf@mail.linkov.net> <2387160a-717f-4164-a0ad-cd831cabd60f@gmx.at> <86cysy1c7e.fsf@mail.linkov.net> Reply-To: martin rudalics 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="37884"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 69093@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 16 10:40:58 2024 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 1rauiH-0009dC-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Feb 2024 10:40:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1raui6-00077X-Ku; Fri, 16 Feb 2024 04:40: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 1raui4-00076x-4p for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 04:40:44 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1raui3-0001ij-Rl for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 04:40:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rauiM-0003KE-VT for bug-gnu-emacs@gnu.org; Fri, 16 Feb 2024 04:41: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: Fri, 16 Feb 2024 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69093 X-GNU-PR-Package: emacs Original-Received: via spool by 69093-submit@debbugs.gnu.org id=B69093.170807640712666 (code B ref 69093); Fri, 16 Feb 2024 09:41:02 +0000 Original-Received: (at 69093) by debbugs.gnu.org; 16 Feb 2024 09:40:07 +0000 Original-Received: from localhost ([127.0.0.1]:57866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rauhT-0003IE-C1 for submit@debbugs.gnu.org; Fri, 16 Feb 2024 04:40:07 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:49715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rauhQ-0003Hc-Vy for 69093@debbugs.gnu.org; Fri, 16 Feb 2024 04:40:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1708076377; x=1708681177; i=rudalics@gmx.at; bh=BLnrmsX3ERvTagvC0G1eJEkNncfL4yIIRob7g/3rXnU=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=ZoAZMBLEwHrnl9OoM7O0h6Py0Ml2cN0hb03rBS/iesxXWvOBA0MxAp6cza0IDHic 92W4qDMYkNtZioH8kewXw8THk8vLj9B/3cRxvARomwBaUjnVPZ/86Xy0pCjGBDqbO 3fUBZwTBkgILbgOh+v69+goZBBuwdmof8lD5Y7Pw1JEnET3g5vAPwHde+ctuJnLMw 4SWCeqhlCuZgiddpLQ8R1Lyy+TOQDSu6bH2Rgvbt0kjYh7pzQpEgwxOq+WMm7sUoC mNV0nJoPiul0UjrpS5ZDKHX0oeqyFtX24hSAFOzQ4QGByFyAqJWP1dVsqYe77xCWe ufUTFlRNu/uu0JwYJg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([46.125.249.69]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJmGP-1rGtlY2o6T-00K7dQ; Fri, 16 Feb 2024 10:39:37 +0100 Content-Language: en-US In-Reply-To: <86cysy1c7e.fsf@mail.linkov.net> X-Provags-ID: V03:K1:VwPOUtGGLyBh+oGVdZAE0di2XYzX6P8fsCkXKdWGWy72ZSy6T6z MaYBycK9k5a2+/ATpUMv1jkOOeoZEVFEG5F+NCNJNYrE4ge0aK6x5mi62u4Azj6D78LNNCH WmxppTFr4TW4FN2UW9e0IYFAgbK/saoN9UTgZHggVxQxY3VGI3TPk/aPTJd5he+qO6S2iI4 qiJuSDWx8n3DYptK6NdRQ== UI-OutboundReport: notjunk:1;M01:P0:KaLGIkRfH78=;uz+xNau7K5uam8IMQvEzl7Oi16d 21ioMHBCzOXiT/7zlcO/H9tOwBJEPtIE5XeyN4p24DfWCnO2th7DaX7C2GLGcpVp5k9+Np+Ip syOL9dBr5Ohm1tV8lQ8wSJrYJEvERvBODaEbRawHE1m1N733jF4M3QACbey023mG/QAdfECoZ VvoFwryiPXS909zji6ac9OzZhFWzrt+LXHRLntdIVXJ0kyw6WzzTSVhNHAUv1w4ThMFnelCyv Y+7z+XWDaLXcCWSG4mqRFpRM08qWzrpiRVjv7S/ONKk7Cul1mKysUvCQNsFjpORay+lYxq449 SpTcUTuFXKM2ILhVBo6uKV9Spf9U2mgAYhE9l1kqc1ts8uJy0a7fdPA6WjDauJGPoy3BKaiWn x3JqjwbgsmcrGPfln+qKHi8vOkYuLtnxtzvJ2O7VqCrBjZUloLBmcP+9oRd+U9T2UgAJ0tHSK fUg1PCIcTR5PfvFsINijl2yA2Ta6bfvj0gHtWD4Algcxb6pa8Ao21CK0cz45yHJIxEqgpl7mH TZ7bITYVfdQ4ZNC/U4AqG2QG4L6GlIsRfuYYtGV4h+gHrQVJsuk90w8lKL4ftKPmaP/Pq4HVo g5/39Sk7dbOwA2izxphVv8tzYSK3Szqp0gyDYkzMq7YWLsioalP3qtn3wg0/9pLqeCCMe+L0s 02NlocVGEEONyeOVG2NtgwKScyypJufmFRY+KlWWCm1Jgc2Wv7xgRGD4YmqixMc5KfGlfRwkt zwNWgjfNjfACu9sFyqJbnL9LlYUZYMY4eWgNTEPn9XwbtSXVf6duCIt+ThrDH7dDO128AFQs 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280095 Archived-At: > Thanks for explanations. I see this line in 'set-window-configuration': > > Fset_buffer (new_current_buffer); > > Do you think this is the right fix? No. I think the right fix would be to remove the above line from 'set-window-configuration'. We can't do that because some applications might depend on the current behavior. But I am quite confident that nobody fully understands 'set-window-configuration' anyway and can predict what it does when selected frame, current buffer and the buffer and frame stored in the CONFIGURATION argument mismatch. Or could you tell beforehand which buffer will be current after (let ((configuration (current-window-configuration))) (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame))) (set-window-configuration configuration) (current-buffer)) I think that the behavior of (let ((frame (selected-frame)) (state (window-state-get))) (pop-to-buffer "*Messages*" '((display-buffer-pop-up-frame))) (window-state-put state (frame-root-window frame)) (current-buffer)) is much more consistent in this regard. I'd say that any code run in a state where the buffer of the selected window and the current buffer are not the same - regardless of whether this happens when a state/configuration is saved or restored - should simply report an error. But that ship has sailed long ago. martin