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: Sun, 02 Dec 2018 09:33:57 +0100 Message-ID: <5C0398F5.4090101@gmx.at> References: <87k1l6f9li@posteo.net> <87muq23vsk.fsf@gmx.net> <87h8g9fpl3@posteo.net> <5BF7AF19.4070809@gmx.at> <87bm6fyf78@posteo.net> <5BF84EE6.9020004@gmx.at> <87wop0and5.fsf@mail.linkov.net> <5BFBBDC5.10706@gmx.at> <87efb7fjm1.fsf@mail.linkov.net> <5BFCFB87.6060005@gmx.at> <87zhtudq0i.fsf@mail.linkov.net> <5BFE5334.3080502@gmx.at> <87sgzkn4vj.fsf@mail.linkov.net> <5BFFA3D4.6020809@gmx.at> <87in0fa4dh.fsf@mail.linkov.net> <5C00F30F.2040309@gmx.at> <87efb0g9sh.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 1543739596 30157 195.159.176.226 (2 Dec 2018 08:33:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Dec 2018 08:33:16 +0000 (UTC) Cc: Stephen Berman , 33458@debbugs.gnu.org, v88m@posteo.net To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 02 09:33:11 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 1gTNBe-0007hK-HO for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Dec 2018 09:33:10 +0100 Original-Received: from localhost ([::1]:43829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTNDl-0004Gj-3k for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Dec 2018 03:35:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTNDZ-0004BP-1G for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 03:35:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTNDU-00045M-3r for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 03:35:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53299) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gTNDS-00044f-FZ for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 03:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gTNDS-0002TR-CT for bug-gnu-emacs@gnu.org; Sun, 02 Dec 2018 03:35: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: Sun, 02 Dec 2018 08:35: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.15437396529407 (code B ref 33458); Sun, 02 Dec 2018 08:35:02 +0000 Original-Received: (at 33458) by debbugs.gnu.org; 2 Dec 2018 08:34:12 +0000 Original-Received: from localhost ([127.0.0.1]:57550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTNCe-0002Rf-IE for submit@debbugs.gnu.org; Sun, 02 Dec 2018 03:34:12 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:35565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gTNCd-0002RO-08 for 33458@debbugs.gnu.org; Sun, 02 Dec 2018 03:34:11 -0500 Original-Received: from [192.168.1.101] ([46.125.250.94]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MMjgF-1gaEHm1ll9-008Yoh; Sun, 02 Dec 2018 09:34:01 +0100 In-Reply-To: <87efb0g9sh.fsf@mail.linkov.net> X-Provags-ID: V03:K1:870sqx5KA1bP/1pk+/JWZXYipncmjeah+WuyPP95PoAdyjVwBOU OdbkNRxrz9l4IE9759MVrFNSd7XLFEDMOmUDWHRrDt97Y04ymYVPdsv9E7NkqLUN9XtUDo0 BInisB0ssVq9pz+U4DdnpUrnBDMlh8aPZuTI2UfObFFdElm1bKhmC3M6/klNVImnR6ffEsA V0cKypf3ttzJY5DVp5wFw== X-UI-Out-Filterresults: notjunk:1;V03:K0:B3dscbDwpKk=:eOMOV+T8GxnS9ICyAK96jq 2KlwX9OMaWCG4YeXvix2Qcm/2gcOs3U6yv7R2Wd/w7JHxyJGz/Ch9Q9PnLD/CqlcMryuMGZgG vXUrOJKHIZl02LOZK5noxTiGI3b5jWM8bcmN19D/jL6kvfYYt3NoJg4U636zjpCst97i49eZA Fgo1/psVJ+c62anaOwKTpHEOPQnKgg7GfBpYKfOUTKAoRdIpxdw+kjTNPgDwANyYVFqFmB43k VOG8UHskqH95j+YbA25hwCuqLJQXJoH3fh28u1fBG6Cez2HaPSuVmiyh7DMxBFa563DlZiF8A UPnWqX1pgnVhIJ7cvuYJervTNz8EK2FCmvvkQgFw8K9n07gtUAzDHpCXI0byYcDtARt1qcX5i ueT4Wx2USAvF0Czn2fYZO+9mM0FGRvEbZqryoQcbt3E2c53OW0Bg1HIP/l7TgjI9ZRzhRIBxp p99cesDZPPm0Ef0pabPK8bFK5GIKk+WhnJayEZIlT5CEZ5Egxn73bPDYwC3GSQx5sRr3Jt5nc 0LDllrMWhv9DMUJ/Hz1Gyk+mVLfAhuG9ntgg1Hu7eOR56mbroftaBtJhfibLpKzu6xcvSHU2V oNS0ue+Cmn2BeJWGQBf4RIidOVdIkPQcevU5ZvG+pOxNghy3zGrEPJ/QCsvjr2HEPrhQItGP/ zbKMtGPkn6OgXEt0v3+gqbxGejQ/bJtIaWxC2eW1FUIiV4YlrZG8cyv57yT/AW4MCmVqHKj7v KxXK2zyZAGCXBG6kQM6XpbL32j8DzdhLhIyW7Jk3dmNEIDhJYCmr6uY8pI2zpzD9pUzRg1S4 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:152997 Archived-At: > Code that sets 'window-point-from-point' could decide how > 'window-point-from-point' should be used, e.g. if it sets > a value 'all-windows' it affects all windows, if 'once' > then reset after first use, etc. The mechanism must be robust, in a sense. We have two possibilities when reverting a buffer: (1) Trace the buffer markers we find in each window's list of previous and next buffers via get_window_points_and_markers and update them via restore_window_points. This would slow down reverting to some extent and not handle markers stored away in window cofigurations. (2) Associate window point markers with some sort of time stamp and compare that stamp against a buffer's stamp which is increased each time the buffer gets reverted. If a window point marker shall be restored and its stamp is out-dated wrt that of the buffer, automatically use the buffer's point instead and leave the window start position to what is needed to get its point on-screen. So far, I think we should adopt a hybrid strategy. Handle a window's previous and next buffers using the first approach. Handle window point markers stored in configurations using the second one. > Then better idea: add a buffer-local variable with an alist > mapping windows to dired-filenames or any other metadata: > > '((# . (dired-filename . "file1")) > (# . (dired-filename . "file2"))) Alternatively, we could replace the point/start markers in a window's previous and next buffers with these file names but this would mean that every time we switch to a buffer we'd have to check whether what we stored there is a marker or something else. OTOH some automatism must check whether and how your alist mapping exists and resolve it in some way. Maybe a buffer-local 'switch-to-prev-buffer-function' (consulted during switching) and/or a 'save-window-markers-function' (consulted during saving) would suffice. martin