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: Mon, 17 Dec 2018 09:06:47 +0100 Message-ID: <5C175917.4010702@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> <5C137900.7010704@gmx.at> <87r2ehro5k.fsf@mail.linkov.net> 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 1545033976 16192 195.159.176.226 (17 Dec 2018 08:06:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Dec 2018 08:06:16 +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 Mon Dec 17 09:06:12 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 1gYnul-00045A-W7 for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Dec 2018 09:06:12 +0100 Original-Received: from localhost ([::1]:45325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYnws-00015W-0M for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Dec 2018 03:08:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gYnwf-000148-Kg for bug-gnu-emacs@gnu.org; Mon, 17 Dec 2018 03:08:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gYnwY-00050i-RB for bug-gnu-emacs@gnu.org; Mon, 17 Dec 2018 03:08:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46543) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gYnwY-00050Q-Le for bug-gnu-emacs@gnu.org; Mon, 17 Dec 2018 03:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gYnwY-0001uz-CO for bug-gnu-emacs@gnu.org; Mon, 17 Dec 2018 03:08: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: Mon, 17 Dec 2018 08:08:02 +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.15450340247282 (code B ref 33458); Mon, 17 Dec 2018 08:08:02 +0000 Original-Received: (at 33458) by debbugs.gnu.org; 17 Dec 2018 08:07:04 +0000 Original-Received: from localhost ([127.0.0.1]:50799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gYnvc-0001tN-5e for submit@debbugs.gnu.org; Mon, 17 Dec 2018 03:07:04 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:51831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gYnva-0001st-50 for 33458@debbugs.gnu.org; Mon, 17 Dec 2018 03:07:02 -0500 Original-Received: from [192.168.1.101] ([46.125.250.88]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4nYT-1hM4aP3zrh-00z1OS; Mon, 17 Dec 2018 09:06:53 +0100 In-Reply-To: <87r2ehro5k.fsf@mail.linkov.net> X-Provags-ID: V03:K1:z7PzmdVQXyPpIF5CT9S6gLuheGMTI2biSFSlXMpXEwLhdYiJM7d g/P6DP8V76dALfDD6Nn0Ea7J5Ehg/WeMvY+gOS86oSrY1Q7fBuxi9svEpecvKvc3ZjYlJPh PJ9T89bAE7DDfq9KjhWw4rwNBf+ztEub6Ijv4gWGUkxw5Kaerc6CpFsD1zhmzqCDf2LIspz 4Ng1Lr9b8ICWeEk/sspgQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Zxch7nc1Iwk=:oTSjv26JwXswbXM8vXc3JO USyf4XBt5sMGh2BBRX7p1IyWMud5vupL2r3Q/tnQfktEcnUdWnM82S3INSHEv9EhFQUHipeVx 2o+41ISFEWPeSVb79meX6nB5TR0xPByyBu/I9bFtCUvXNntUwkU9PZ/6agb/+zErEbod7em2H gieI82s8C4/SkES/io1QSJErKpYdCC7SJFueq7YpgyyX6A1YYjyhHfavL4wZlKa1ZpxJHyVnq u6MaFZ7eUuS/gfj80AlDbEddARF+O8UibC9TMj8SuErLb1ygw3M2qTI/lDqc9V9oe97on/TRl dQLhBYbMXYNmCulf0wpYOZLxAkykiRCeY6/WnPNGcpPgG6YbUU2AvKajBa48npBtWquiTzuXj qqvDBiPimRNXeGPCEzHh+vQWOo4EZlZHUWNvgHqlhXbzypKt+N1E0oIUYMdpbpDevoGiP9e3V EDKgK04OUXtPwAEzbaBBVcZlVf/RBdncYJQqGLPgF4R5CS6mqFcZzub1DI30+br4ZOegMTnfU wGUvACpqBitezWX2T6Iv00UzoQSYy+Gz8quPHbtxOpnFb+Rmzwpr653Gcthau+fbj/px4KSqL JFrdRF/2BVDwihtfPfk2iqHtGifgfIFyDjbwkTuqaJXv5aypbOe/hIewN3vX4iCCuQaWHENv9 gc2cl2K9BaDyF9yH2x8I0r/hhRlkA6mbY3/R2/S9TGyI9rnH4OCQobdl4avOPMBBKKGGwY2mJ ZNFHhZDYbj8DtrW7MdvBoxeFieTyDzNFn3D8CIm1UK1lF/ZKIN9i20FYP9VX9YU7Zc9nBHei 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:153507 Archived-At: >> 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? > > Another question: When should the buffer-local reference be added? > > Every time when point is moved to a new file? Too frequent calls especially > in cases of e.g. pressing and holding the spacebar to move thru the file list. > > Or when current-window-configuration is saved to a variable/register > or window-state-get is called? I don't know what hook is possible > to use at that moment besides advices. I'm not sure whether my scenario above was entirely clear. The "buffer-local reference" I was talking about would be a buffer-local list whose cars are all the windows (including dead ones) that showed the buffer before. When reverting a buffer, we would traverse that list, and for every window in that list (including dead windows) look up the buffer reference in that window's previous buffers, calculate the new window point position from the old position and store back the new position as marker in situ there. For dired, for example, one would go to the old position, look at what file is displayed there, remember the name of that file, revert the buffer and in the reverted buffer search for the file name and store an appropriate position as new window point for that window (including windows still dead). For other buffers we would use the default 'revert-buffer' function and have it do whatever it does now for live windows showing the buffer. In either case, reverting proper would be oblivious to whether any window point it transforms is that of a live or dead window. Still this is nothing for the faint-hearted because the only surgery we allowed on dead windows so far was to resurrect them in a restored window configuration. So the answer to your question "When should the buffer-local reference be added?" is the earlier alluded to "in (2) when we unshow that buffer in a window". And the problem we have to solve is when to remove such a reference because the referenced window is really dead and no more referenced by any saved window configuration. Note: We alternatively could store the position information from windows' lists of previous buffers as buffer-local lists. This would make reverting slightly simpler and switching to a window's previous or next buffer a bit more complicated. But we would still have to find out whether any window referenced that way from a buffer is still referenced from a saved window configuration. martin