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, 24 Dec 2018 09:15:36 +0100 Message-ID: <5C2095A8.8090206@gmx.at> References: <87k1l6f9li@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> <5C175917.4010702@gmx.at> <87va3riqvm.fsf@mail.linkov.net> <5C18AFC7.40200@gmx.at> <87sgyrae4s.fsf@mail.linkov.net> <5C1CAF40.60104@gmx.at> <87imzl6tks.fsf@mail.linkov.net> <5C1F5828.3040303@gmx.at> <5C1FDCCB.1080404@gmx.at> <87o99bkdpj.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 1545639250 5638 195.159.176.226 (24 Dec 2018 08:14:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Dec 2018 08:14:10 +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 24 09:14:06 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 1gbLNF-0001Le-11 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Dec 2018 09:14:05 +0100 Original-Received: from localhost ([127.0.0.1]:33772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbLPL-0003Ex-N8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Dec 2018 03:16:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbLPG-0003Es-3R for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2018 03:16:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gbLPA-000853-E4 for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2018 03:16:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58214) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gbLPA-00084v-A5 for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2018 03:16:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gbLP9-0005GG-Vm for bug-gnu-emacs@gnu.org; Mon, 24 Dec 2018 03:16:04 -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, 24 Dec 2018 08:16: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.154563935119463 (code B ref 33458); Mon, 24 Dec 2018 08:16:01 +0000 Original-Received: (at 33458) by debbugs.gnu.org; 24 Dec 2018 08:15:51 +0000 Original-Received: from localhost ([127.0.0.1]:34239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gbLOw-00053V-UI for submit@debbugs.gnu.org; Mon, 24 Dec 2018 03:15:51 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:43181) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gbLOu-0004xK-NC for 33458@debbugs.gnu.org; Mon, 24 Dec 2018 03:15:49 -0500 Original-Received: from [192.168.1.101] ([213.162.73.205]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LlVZv-1hCKF90X4B-00bKNO; Mon, 24 Dec 2018 09:15:40 +0100 In-Reply-To: <87o99bkdpj.fsf@mail.linkov.net> X-Provags-ID: V03:K1:7HL4RwquxaY0tD+CTvTtMMrBV5EJCMsVkk1VOxQ66DHNElyHFRO kJ5tc0nFiBV347ud9lfs/n1FaRycpBIRUeN/TzNuu1qfBtRNkNz3V7eVTbT0l6lfgzYBTqw HwLBHuL4g38rV1f6a63W7Ud1jtQwt5k1MYQcD2yDmVLcYGWLFKBanMIE5PoS6FXYWhzC+zO RYDzR7/jAHGifz9OEgesw== X-UI-Out-Filterresults: notjunk:1;V03:K0:gtb6rrTlFlo=:GTG9Evqxrw1j7981DgTlv+ DQaSacwwWupI82v8dnJKJJpipxalORSAXrDQaQ+CFLeZRZlrNonz+sDH8Ne/vtuJvkloAKTRC bM3t/MR4J0KZBSzliRVauv1NDNdfNDA0IH4axMb8sS/mjUZPq4Zdq+mnl2KEDkVGe2zPRAzB6 GV/XtgW0cbq0TCbT9UpIxaiGUig35408b7CgR6h6Xm0Lva5R4zy3RHBdFHCyDU6FiYj73q7BB j4F+kNpP1fbzeTjHmoB/kyNLRz0U3CJID9LfCf1GBONs3wqV9e73+vEzIJTjzeNWXBDdNCCEw GwrSGOaeMpCkvXxIMmJqiCftz9V2bU7lrUDkFdkETDUATRMcjmERM5qodzWC0o51inPGaaHOl AXl6CHCpexxqPTCMGTmN8/uINtnZ48OlgpBWsJWnrDE10F9yJmcMe5V4E1i+fbYd3ErWHuoyh M6OOpbzKUbpriJuaH48zZM1E/m1dt9cNC0wYDH/g5qAzjr5NFxrz6K01JdCA43Y699kT6k50x DrkRK0EfV2lRJiHGQNX0AHn7Z9iAEn1bjutiPpqU2pS6UlZCA76JH6S8BnTlnRfWAtjWQvJBW 7/QTdIVTnYF/fEiNEAdZ5/Dl8alSyHjmbb+XKkGkGmS6wP26KDAdYkNp4JwYaAZuT/8g8XWrQ 4TcFasiGNC2jVyOiLiiHFY3Vy0o1moKODL7Ik29y56mWcwirfLEyNffwyowsfkAlsg7zhpas8 vdFmplEePqx32Fb4K8oaF6JQ/wMLoi1iDLhLQ9hddK+HuXq3llwDHZrc7yTg1TBhR75+gFtP 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:153819 Archived-At: > Thanks, but I expected it to be more configurable, i.e. to also look > at prev/next-buffers in a saved configuration when needed, etc. We can easily do that. But note that a window's previous and next buffers are stored in the window itself (where, if the window is live, they can change at any time) and not in the window copy stored in the configuration. So there are two solutions to your request: Have 'buffer-windows-from-configuration' return pointers to those two lists or have say 'window-prev-buffers' accept dead windows as arguments? > This could be achieved with a complete export of the saved > configuration to a Lisp structure. It's a bit tedious to code but can be certainly done. But I suppose that what might then interest you just as well is to transform window states into window configurations ;-) Also, the function as I wrote it could be easily complemented by a function say 'set-window-buffer-in-configuration' where for an argument WINDOW you could perform some surgery in the configuration like setting its buffer (when it gets killed) or its point or start position (when its buffer gets reverted). > If you think this is too big task, then a simpler solution is > just to create such metadata structure before the configuration > is saved, and save it along with the configuration. I already do > this by saving a writable window state parallelly with saving > a window configuration. What I mean that in a package that > saves window configurations, maintain such a list: > > ((window-configuration-1 writable-window-state-1 metadata-1) > (window-configuration-2 writable-window-state-2 metadata-2) > ...) > > where metadata could contain a list of buffers from windows > and from prev/next buffers, and everything else required by > application logic. The problem with this is that states you save this way get outdated wrt their corresponding configurations: In particular, after (un-)showing a few more buffers in the corresponding frame, the configuration will be aware of these changes (because they are stored in the lists of previous and next buffers of the live windows) while your saved states won't. Finally, we probably want to do some of the things on your wish list automatically for all configurations referenced by some particular list like say 'registered-window-configurations'. So maybe we should think about such a structure and how to maintain it now. martin