From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#33458: 27.0.50; dired loses position when reverted from outside place Date: Fri, 14 Dec 2018 10:33:52 +0100 Message-ID: <5C137900.7010704@gmx.at> References: <87k1l6f9li@posteo.net> <5C063BD6.5020707@gmx.at> <874lbt73s3@posteo.net> <5C079794.6080500@gmx.at> <5C0B91AD.4050909@gmx.at> <87y38yjkqk.fsf@mail.linkov.net> <5C0E1C9D.3040106@gmx.at> <87pnu9j5lh.fsf@mail.linkov.net> <5C0F7695.1070408@gmx.at> <875zvzlgqm.fsf@mail.linkov.net> <5C10C786.3030504@gmx.at> <8736r2fhnp.fsf@mail.linkov.net> <5C12200E.8060609@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1544779991 27941 195.159.176.226 (14 Dec 2018 09:33:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Dec 2018 09:33:11 +0000 (UTC) Cc: 33458@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 14 10:33:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXjqE-00079k-NM for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Dec 2018 10:33:06 +0100 Original-Received: from localhost ([::1]:60475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXjsL-0001EQ-G9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Dec 2018 04:35:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXjs9-0001C5-L9 for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 04:35:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXjs6-0006ao-Fp for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 04:35:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43060) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gXjs6-0006aR-8y for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 04:35:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gXjs5-0007A7-So for bug-gnu-emacs@gnu.org; Fri, 14 Dec 2018 04:35:01 -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, 14 Dec 2018 09:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33458 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33458-submit@debbugs.gnu.org id=B33458.154478005427463 (code B ref 33458); Fri, 14 Dec 2018 09:35:01 +0000 Original-Received: (at 33458) by debbugs.gnu.org; 14 Dec 2018 09:34:14 +0000 Original-Received: from localhost ([127.0.0.1]:47315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXjrK-00078t-3J for submit@debbugs.gnu.org; Fri, 14 Dec 2018 04:34:14 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:40459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXjrI-00078f-F8 for 33458@debbugs.gnu.org; Fri, 14 Dec 2018 04:34:13 -0500 Original-Received: from [192.168.1.101] ([46.125.249.80]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9Jss-1gjFeW2I3y-00CfxI; Fri, 14 Dec 2018 10:34:02 +0100 In-Reply-To: <5C12200E.8060609@gmx.at> X-Provags-ID: V03:K1:CGQ/RzO6zmObc245UaOEAJP9RZNIC18vQOZcpJXii94/hQt64m6 GvxYzWqROVpH1JeeGLQB2WbIL1kzr0MWzTbwEXSdsdJ0exts2Ixbe0NjNvoqmHBQUHQHyr5 Dhqf+74VDDgsK0xsuHgxRRmYwddA1FRZ0VlKXs7wlRxdmBdAFjUBb+tNPXSFF/g6Xb3Hprl xqingxJoFv0mBJgXDfO7g== X-UI-Out-Filterresults: notjunk:1;V03:K0:JI061YlwzCQ=:odgUTFoo2krb9bPGvfuhz/ TfdaMaZFjaI0Luvf+BsBg+BOKaTzr2lntZMifu75bBqPex5oWq2OYFvuXfdChkU01/35E25PT 0RTuBuuSROhIZN5erIhv6j9G1dhlbtPAERV/0+Psp7Dsh+/DCF9O8zvQQBm7jAuDRNQMwXTQi aGRx+bgiw7TtL07ZJPMXRvpM2ehqBpEfGmNhLfRg4uwWmhcgCOxf4mtBb/25qzNiFUx3FcM3A 15DVaLX8FG6PpisRgqxmcvChH5Z50Mf5KUq6/6Wmw2mSg+SQxcK8C8pbuexaZj+8RFLCcWVB6 vMS2nDUFYS1cHezICIX6rXim/qEeCFpHuCvPmfEONFjB4EuUyIzOWya5zWm3Hf87B6Hg1Gvb/ RfFkA9sB3HfZ/guHe1M+ltZtgsr56fVBbsiAGpj5AJGl0Q0ixqvdxKa018IraOwyUDfFIl+gb 2USnwcnv2LXaI7es9t8E0EdVFDdkTJuTY6i2rj3X/R3kQl5IaeMTqt6gdcZ1u05rJ4bpieDBB OTXz0QTY/UZrAyyVnc+5PRnqtTwz3JVnHObi90QxPnSMlckQOkHYltf1Aep6jq0K3dSiV5CR4 3RCnrNfiAANPOe0y6AGLB86+vlYvfaAnxJTCoZAxTpKFW7ZUv8W09sft0kVK6foVKFw85xwSM zCi/j1ySnGHbazUq8BX4FLBLG889RrkKMpXOJsyAY9+87kZgVmCusz2ZkHdlwmzjhngRJ5S+3 QTF92kBi33r+E1HfEhMwcflGLWJhhsYbbWwKajp60ybwTp/zn6Wo3oNkweEb+Pwiwy1uXX6n X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153442 Archived-At: > The downside of such an approach is that any buffer-local reference to > a window will assure that the window object cannot be reclaimed by the > collector as long as the buffer is live, even when the window is not > stored in a configuration any more. Not that I consider this a great > downside though. Reconsidering ... Imagine a scenario where a user (1) displays a buffer in new window, (2) switches in that window to another buffer and (3) deletes that window for good. When and how would the buffer-local reference created in (2) be removed? It can't be done in (3) since a window configuration stored somewhere might still need it. But if there is no such configuration, it should be eventually removed since otherwise such references may pile up and inhibit reclamation of all associated window objects. Unfortunately, there's no way to find out if such a configuration exists. Obviously, when the buffer gets eventually killed, its local variables get killed too and the reference will vanish. But in a long session many buffers may be kept around for a long time and every time the above scenario repeats itself a new reference will be added. The only way to solve this dilemma I can see is using the collector. For this, any reference created in a step like (2) would have to be considered weak, that is, would not be be marked from the buffer-local list. When the collector sweeps buffers, it would have to perform an extra check on that list: If the corresponding window was not marked so far, it would be considered definitely dead, the reference get removed from that list and the window be reclaimed in the subsequent vector sweep. As if things were not already complicated enough, any access to that list (needed when reverting a buffer to update the point position for every window showing the buffer in the past) would then have to be atomic (not allocating) to avoid that the collector reclaims a window under the feet of such an update operation. Finally, this would not help wrt window states because these do not care about window objects in the first place. So I think that implementing a scheme based on buffer-local window references is hardly feasible. Admittedly, GC should do something similar when sweeping window configurations since these may still hold references to killed buffer objects and thus prevent their reclamation. But that would be fairly simple since a buffer that has been killed will remain killed forever. OTOH, a window that has been deleted may remain in a zombie-like state until the last configuration referencing it has been removed. martin