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#32850: 27.0.50; window-swap-states doesn't swap window prev/next-buffers Date: Fri, 26 Oct 2018 09:39:25 +0200 Message-ID: <5BD2C4AD.3060402@gmx.at> References: <875zyrrhk8.fsf@mail.linkov.net> <87o9cepxfv.fsf@mail.linkov.net> <5BB1DC5D.2070903@gmx.at> <87ftxgqcx0.fsf@mail.linkov.net> <5BBC5C61.4090901@gmx.at> <87ftx79brv.fsf@mail.linkov.net> <5BC5A536.7020603@gmx.at> <8736t57jcs.fsf@mail.linkov.net> <5BC6E559.3090000@gmx.at> <87zhvcteuy.fsf@mail.linkov.net> <5BC83EE4.8030607@gmx.at> <87h8hig9uw.fsf@mail.linkov.net> <5BC98A5F.5050807@gmx.at> <87ftx0nvoi.fsf@mail.linkov.net> <5BCC374E.603@gmx.at> <87a7n7kz7x.fsf@mail.linkov.net> <5BCD935F.8030309@gmx.at> <87in1szirt.fsf@mail.linkov.net> <5BD03F21.6040807@gmx.at> <87lg6map8e.fsf@mail.linkov.net> <5BD15CE0.7080703@gmx.at> <87va5qf1ox.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 1540539489 30632 195.159.176.226 (26 Oct 2018 07:38:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 07:38:09 +0000 (UTC) Cc: 32850@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 26 09:38:04 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 1gFwh1-0007pU-6k for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 09:38:03 +0200 Original-Received: from localhost ([::1]:58686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFwj7-0000Hb-Er for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 03:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFwiz-0000HR-W5 for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFwiw-0004Fm-5a for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:40:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38891) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gFwiv-0004Fg-W3 for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gFwiv-0000FZ-Sb for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Oct 2018 07:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32850 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32850-submit@debbugs.gnu.org id=B32850.1540539586930 (code B ref 32850); Fri, 26 Oct 2018 07:40:01 +0000 Original-Received: (at 32850) by debbugs.gnu.org; 26 Oct 2018 07:39:46 +0000 Original-Received: from localhost ([127.0.0.1]:43149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFwig-0000Ew-AI for submit@debbugs.gnu.org; Fri, 26 Oct 2018 03:39:46 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:33823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFwie-0000Eg-N4 for 32850@debbugs.gnu.org; Fri, 26 Oct 2018 03:39:45 -0400 Original-Received: from [192.168.1.101] ([212.95.5.134]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MILxX-1gIyim0mop-004BR7; Fri, 26 Oct 2018 09:39:35 +0200 Original-Received: from [192.168.1.101] ([212.95.5.134]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MILxX-1gIyim0mop-004BR7; Fri, 26 Oct 2018 09:39:35 +0200 In-Reply-To: <87va5qf1ox.fsf@mail.linkov.net> X-Provags-ID: V03:K1:yxDEJQdcrmV2D049p+S+KyZEao/CRiVNv19IJcB1hkP0AvVnPR4 eighwI763YlVZONr5wLsmJZszRTkfcJKFMSy/Jb3QJlJkFh/+dsEs+Y7KPpojgwllXSXBN0 ySLQ7iRVgLzehPu13f0KeMU0seN3P11AnevEhAeUbz79RpFKkRUDVrdXBh5AJ1oEvfqVpJV y4qsge5Qn3Pjhs9ItWKWw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tZGynAY6BQQ=:JW7Oamh7hauri+1qi5/apU s0SBq0i4kHcYKDyRFXSShilToHftAtEAxjZpDAW6mbYddFM0WXRIRs2b0OdAve4pxS4Q2b1sQ 2Bruh95uTWuTefLon87ZgukznDkUnfpsdJ8FelcbTBZF2qBqwjbTcwj7Xx8gX3ZGwLA3T7aNN fiU6k0vhYNCdbLqJR92lX87Sk+4uzQwWuJ4cZYc+U3UQTBxsoq5peo9BKRBsmDDnMygxrX7B+ ku+SSlOvraDgMPsq0t5PgpCp3yyO1NzyPrHwuEkXtvBgpbEREET0cmFtpExZIRrxRrWO3Kubb SWu1tNUOxhreMgIeicPzuFiSUL2gAQ+NqMmVF65sXVMSXfDtCh8F2E6b3XnMG471v8cXhW5Uz IHv6yar2LFvd8B7q+ydGufulBmfPUUt1a2+AzD4S9cF5Ar9VcydCW/DGbWVs5Fxlf5EUgasKg huELfwINvbOJTHbTS2rW5ukvC7KbUVYBxl4n99/OnR4+toxSQ30QP/+7hDzx6MgvuCS64P7yd c4GdFIwOKAHhRmn1yZ7t1f/0ljLJMD6J7raWgefinvM0qMwSAV9XR7C6OLRIPCMRACuZcB+RS 9WRhM1WdoXD4ITsNppjuXx4MRgizCWB3UC5kqNnzY72pBJSPDOiRnf4ecK/dZRLeHWuPDUnOI Mmvk/aXT4TQPBNR6UFq/YFYTjHQ7IdP3Am+bAcX4SCepvxturoaUV1w0+MqzFteRvPld9VGvi 4CytVMSKSndafaaK2luODIcJazXGGja6J4EAGXFLENVcHO/Orv7iM+MBv3GSbeblNcoupv3u 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:151635 Archived-At: >> Which problems do you see in practice? I have no idea about the >> internals of desktop. If you mean that the windows' states have to be >> saved too often - > > Yes, too often - according to desktop-auto-save-timeout, it should do > this juggling with window configurations and states every 30 seconds. That's not reasonable. More often than not this will catch the current window configuration in an inconsistent state where the minibuffer is active or the user is in a window excurstion. But does desktop save window configurations or states stored somewhere in the first place? > In fact this means maintaining a duplicate data structure, > i.e. in parallel to keep in one list - window configurations, > but in another list - window states. The downside is data duplication. > If this is the only available solution, then it's ok. > > But the problem is that window configurations can't be used > even in the same session, because they don't keep prev/next-buffers. ... > But unfortunately set-window-configuration doesn't restore > the old values of prev/next-buffers. That's disputable anyway. When, in a window excursion, you show some buffer in a window, don't you want to record that buffer in that window's list of previous buffers after exiting from the excursion? Anyway. It would be tedious but probably not impossible to provide a function that transforms a configuration into a state. Doing the opposite is conceptually questionable, at the very least. A basic invariant of the windows code is that a valid window cannot appear twice on the same or a different frame. It may, however, appear an arbitrary number of times in stored window configurations. One consequence implied by that invariant is that you can restore a window configuration only into the frame from where you saved it earlier. When a frame gets deleted, all configurations drawn earlier from that frame are virtually lost. martin