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: Wed, 26 Dec 2018 10:42:40 +0100 Message-ID: <5C234D10.6070609@gmx.at> References: <87k1l6f9li@posteo.net> <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> <5C2095A8.8090206@gmx.at> <87muotnvsa.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 1545817815 12480 195.159.176.226 (26 Dec 2018 09:50:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2018 09:50:15 +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 Wed Dec 26 10:50: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 1gc5pL-0003A4-7Q for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Dec 2018 10:50:11 +0100 Original-Received: from localhost ([127.0.0.1]:45225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gc5rR-0004Qu-VT for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Dec 2018 04:52:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gc5rD-00043w-TZ for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 04:52:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gc5iQ-0004Il-HP for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 04:43:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51924) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gc5iQ-0004Ic-D3 for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 04:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gc5iQ-0005zR-AF for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 04:43: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, 26 Dec 2018 09:43: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.154581737923014 (code B ref 33458); Wed, 26 Dec 2018 09:43:02 +0000 Original-Received: (at 33458) by debbugs.gnu.org; 26 Dec 2018 09:42:59 +0000 Original-Received: from localhost ([127.0.0.1]:36591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gc5iM-0005z7-Jx for submit@debbugs.gnu.org; Wed, 26 Dec 2018 04:42:58 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:43831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gc5iK-0005yu-W2 for 33458@debbugs.gnu.org; Wed, 26 Dec 2018 04:42:57 -0500 Original-Received: from [192.168.1.101] ([46.125.250.34]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MWhRH-1gqdnI2zIx-00Xp3M; Wed, 26 Dec 2018 10:42:47 +0100 In-Reply-To: <87muotnvsa.fsf@mail.linkov.net> X-Provags-ID: V03:K1:uI+7cCPEm+KQuo7Bydt1KfJyxeQ8D4RVne1mawtSlaEpgeOnVHx yM1ViCOsTTfQi4d3tW/DjTyECJoleiDaqKICtiFzDXeHOgy27mmFGIAP8GrSP9zYzBU63BY to4uMNPzOvBMB1ESDqBANPRCe+plzs4MRircHt3X98P/s7FqEMBQ08PoyHSk2qL6F5GNZbU wahvOiwqsi/r+SVXqfryA== X-UI-Out-Filterresults: notjunk:1;V03:K0:NsNxe0KDtv8=:ttHS9FYC8vTwWZO7qgkF0c 6D6AQAgrOgbQmDKPMeJ6xu8bd7EuPdYfoPm0t7m6Ke/NhoFvNWEm90tSV+cZa0SJ9vxayC/Sr y2U/4e5s3E9I7DiIfPTJQa3YzP62AIm3GyPW2sMezOsrDjBRmrH+PZPPepcN/VO2sCIU6fSos heZcDNQKJ9D3z50/QGuTGJfMm6gyJcJb4f71LW3SGJ4bmTic3B+Rkeg0uHOsoFjMr3xRHdI/2 e73ZKh9J1GsTG/+jXLcVw3SmrTJ6kIV3mHfiGZoWxoXs9TwWoZ13vgphoqHGa+/2xtNkMGnZq NF4CobiI+6yYS3NCWu0yH3TonShffhv+GO87HM8zO7zLGDG3P5t/x3hTxnc1m/x9aENjvGebh a45iZ7Zjsf8ZqLezFDdmxJm531F0nx6t9vJxsR62YgiR+gyVEryT8HYTNuGxWLm3iLAXHUZtW pCE/vVm9FO+RTgqv3w9wM6fVHLbKk9fOyQ2szU+lWZkuuvM71CDLYZ93CToqULCDgmXT+ykb+ VMChdg0YAl3hVGjhHJEi5lAleAxJlDBC43l+qM9HF0FrEuJfjoRXpZui22fvvzP23Nd9sn0+E lk63tFOzPh/8EOEqB8tFu0HclHrX/7U2cT1rcKZL5/CgsDJ3pfJ/EUQ5rdF/YtOV/PG1wI+cx ZhL1wYbPlGE5StG9b/3dOh574wCsHbLAiRtof6U+i7lY7tY2s6pfq6uDY+5cnKxnwfqw7RJ/j RumM9lsorwclATH7onWchz+wfud0xjAq1Su5vtg7Wr+1bnoe8CF1wqA43YW9fqRKQiVUGCm3 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:153864 Archived-At: > Oh, I see now why this case fails: > > (let ((_ (view-emacs-todo)) > (w-c (current-window-configuration))) > (view-emacs-news) > (set-window-configuration w-c) > (previous-buffer)) > > I expected it not to change prev/next buffers of the window > saved in the window configuration, so the expectation for the > last call to 'previous-buffer' was to return from the TODO buffer > to the original buffer *scratch*. But since the NEWS buffer > meddled with the same window, this is not the case. A window configuration is a state, a snapshot at some given instant of time. A window's previous buffers are a history, a sequence of statse over a certain period of time. What you want to do is freeze history. We could do that by making a copy of all windows' previous and next buffers, storing those lists in separate variables and restoring them from there. But note that any such change might mess up the partial ordering of events on your system. The relative positions of buffers in a frame's buffer list would be incongruent with their positions in the buffer lists of that frame's windows. A new buffer you switched to while the present configuration was saved and not yet restored would appear in its frame's buffer list but not in that of any of the frame's windows. This would imply that all windows of the frame were created after the buffer was shown. So I think you should first reconsider any such behavior. Eliding things from history "as if they never happened" is often a bad thing (although I wish Emacs' 'undo' could do that occasionally). And if we wanted to implement it we would have to make it customizable. Hence any package would have to cater for both ways of seeing the history of buffers in a window. > This is why any code that saves window configurations has to care > about creating a new window after the current-window-configuration > call (thus removing the window saved in the window configuration), > like I fixed now in https://gitlab.com/link0ff/emacs-wincows/commit/226cf229 Restoring the window configuration would remove the window. What else would you want to do with it? BTW, window parameters have to be made persistent in order to make them replace current ones when restoring a window configuration. martin