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#33871: 27.0.50; Revert Dired window saved in window configuration Date: Wed, 23 Feb 2022 10:31:41 +0100 Message-ID: References: <87bm59mglk.fsf@mail.linkov.net> <87fsoo323s.fsf@gnus.org> <86h792x3wv.fsf@mail.linkov.net> <119a9c2c-e27f-6c3a-07ad-66bc76fc58cf@gmx.at> <861r05co9l.fsf@mail.linkov.net> <86zgmsne32.fsf@mail.linkov.net> <86sfsi29yc.fsf@mail.linkov.net> <1830e7af-27a8-ac7f-ba6f-fa2006139208@gmx.at> <86fsohmqn9.fsf@mail.linkov.net> <9df28298-fedc-0cfe-7243-c04868115e90@gmx.at> <86fsoezsw3.fsf@mail.linkov.net> <86sfsewvxr.fsf@mail.linkov.net> <9d741b43-e3bb-669b-b345-6b877c902b33@gmx.at> <86fsoaq4lo.fsf@mail.linkov.net> 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="7752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 33871@debbugs.gnu.org, Lars Ingebrigtsen To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 23 11:10:44 2022 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 1nMobc-0001q8-5d for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 11:10:44 +0100 Original-Received: from localhost ([::1]:39290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMoba-00013n-Qx for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 05:10:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53538) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMo0B-0006TF-1K for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 04:32:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49923) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMo0A-0005pe-CV for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 04:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMo0A-0005kV-Ah for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 04:32: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, 23 Feb 2022 09:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33871 X-GNU-PR-Package: emacs Original-Received: via spool by 33871-submit@debbugs.gnu.org id=B33871.164560871022071 (code B ref 33871); Wed, 23 Feb 2022 09:32:02 +0000 Original-Received: (at 33871) by debbugs.gnu.org; 23 Feb 2022 09:31:50 +0000 Original-Received: from localhost ([127.0.0.1]:43815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMnzx-0005jv-VN for submit@debbugs.gnu.org; Wed, 23 Feb 2022 04:31:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:37455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMnzw-0005jb-Gf for 33871@debbugs.gnu.org; Wed, 23 Feb 2022 04:31:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645608702; bh=yClijdD0qr/lPoKe7vf+WUoCl6T/Z/Z0oDXW4xcEH20=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=WKRYmoAoORU2ld1Fpt2TIeiKhB7e6M3P7FLcUOLyYGogqIIAdirI0uB6L+SHaWQae Ho4XZ+GBIL8LvGC+5pywpYEphZKZTeEyIu8P0wAhrbQbcH7mwZgs5+hgM5BiVgOcf0 vEJ66O/dfQlla2Fg8eXHDeTfGmvVJOuhzIqfLCk0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([213.142.97.235]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvsEx-1oCZ4L1YLn-00sx63; Wed, 23 Feb 2022 10:31:42 +0100 Content-Language: en-US In-Reply-To: <86fsoaq4lo.fsf@mail.linkov.net> X-Provags-ID: V03:K1:ehwbSWEXQaS+fq2bu5OvcZ57pYb/8GlQ6shyiIYUpnummY/oibK Egg1V14IsgoRc4QhjpsFiD506cPPPXaPAG5bJIbSBskEaKTYnF4oE9g+WbamCRbARiwSoA5 XwZQCFtUbkMKSzG3BooDXELls+SNHKhOpLz0brnexy0HLwDcJhBccDo9z47MjQMPQg18VzP 4lylpWhojtZ45rqsUijpA== X-UI-Out-Filterresults: notjunk:1;V03:K0:3rSx3hUoZTE=:tMiwJChS302YeHJM84aJmF 6V4QrApnYUFLWXEf2zsyR1ZjTGpLABE90dGMW6Fsda9rOzvIN6oeNqXsgiFTI6HJ+sb/8Gs6U CDSHmQHSqSisTb0cZnuj7k7EvYd4689auhQIXxz35qGO88o0spfos3b/eZkgjr0uGN9fkHRWi 40iugcmWqoxPA66QW/UfKR9N08Y2eHY8KCasblPwBKh4gWEY8J42tDSFRS7QnKzSY0e9xet/0 q9YvkvQTy+UvQebRF3aUu1VDWVU53GEHjxBGXgJ8GQbnmIz6i9aKCcgkD7gfCtDFK6yX65Zji rdQ5231oaUuzWwncwKGZHAwiWbCDVynPsL9ULmu5P93+MQsdUWGdtImzBAVaNt+ab+bkGhFrg kPkiZP1EUAtnWU2GnZUH2nuMCVcU7pgSyMY6iY9eq9r5m7e6+Na/njuSGYQwC88u+5svWoovK worqEBWXN7X9VgD6PQGxYsHzsXxOinVvymlmDLzvfrSFdbNOmImQw/i9KOnoxxsIjg3HzMbvs CsaSr7/8pRHgEGr+27+yvKZEciIPoaFbO/oRWzGj/Gpok3kzJ6eDjDWcAUT3evtG6Sudt/NRU EKm6okDC9NoPiL7E5SnOm9m1Tc5Tgmne6gy4ukzLdXuxw3+HBOVsRN4hp1xtWWEMtLcrPlB/Z JGVlIPWP3tN9awT2H9ypbzcffpyYN6NIaxYCiWg26lkJwmfHj0chu4KkhPyevi+3auNf6iWkR WKCPEZ3DVbDzRqrx9B1vgc3ks4GvzqIRJq/H4VaCWGeU8aOrMGQH/6BneIW1sQa4RxKLy7VG 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:227487 Archived-At: > Like in bug#54038 (about having access to windows in window configurations), > the problem is that there is no way to update and even peek inside > a window configuration. In bug#54038 the cleanup function can't tell > if a window is still live in a window configuration. We might be able to provide such a function but can you tell me why you would need it and how you would use it? > And here 'dired-revert' can't update windows saved in a window configuration. Updating window configurations can be hairy. We have no function for testing the validity of a configuration - we simply rely on the fact that it is a 1-to-1 copy of original sizes and parent-child relationships. For example: When we resize a window we check the new sizes of all windows on that frame before storing them. When we restore a window configuration, we simply store back the old sizes and then maybe try to resize the windows if the frame size changed in between. > 'dired-save-positions' goes to great lengths to employ get-buffer-window-list, > and walk-windows with window-prev-buffers to update the Dired buffer > even in window-prev-buffers. And 'dired-restore-positions' with the > same number of lines tries to restore all prev-buffers. > > But still 'dired-revert' fails to update the Dired buffer in > window configurations saved in tabs, or in winner.el, or > in 'C-x r w' (window-configuration-to-register), etc. As a first step we could try to do that for window states. > A possible solution would be to add two hooks: > > 1. hook before finishing 'current-window-configuration' that will add all > windows to some variable that the cleanup function could check in bug#54038. > This is like 'dired-save-positions'. We can easily add such a hook - an abnormal, buffer local one probably that would be set by dired whenever it shows a directory in a window and could get as argument the frame and/or the window(s) and probably the return value of 'current-window-configuration' so dired can match it with later invocations of 'set-window-configuration'. > 2. hook after calling 'set-window-configuration' that will restore > previous positions. This is like 'dired-restore-positions' that > uses 'dired-goto-file'. We can do that in a similar fashion. But: Updating your "variable" when dired does something (like copying, deleting or renaming files) would still have to be synchronized with the position of, for example, 'window-point' in that window when the window is still live at the time 'set-window-configuration' is called. So we might need yet another hook called at the beginning of 'set-window-configuration' that allows dired to check whether the window stored in your variable is live, take the position of point from there if it is and keep it in the second hook. (Note in this context: We traditionally say in the Elisp manual that "As a special exception, the window configuration does not record the value of point in the selected window for the current buffer." which is not precise IIUC. It does record the value but 'set-window-configuration' does not or not necessarily restore it.) martin