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: Thu, 18 Oct 2018 10:05:56 +0200 Message-ID: <5BC83EE4.8030607@gmx.at> References: <875zyrrhk8.fsf@mail.linkov.net> <5BAD2538.1060609@gmx.at> <871s9e1syw.fsf@mail.linkov.net> <5BB082A6.6040709@gmx.at> <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> 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 1539849908 1036 195.159.176.226 (18 Oct 2018 08:05:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2018 08:05:08 +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 Thu Oct 18 10:05:03 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 1gD3Il-0000BZ-Ei for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Oct 2018 10:05:03 +0200 Original-Received: from localhost ([::1]:40997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gD3Ks-0006Fx-1P for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Oct 2018 04:07:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gD3Kk-0006FQ-2W for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 04:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gD3Kg-00087j-TV for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 04:07:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51859) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gD3Kg-00086k-OU for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 04:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gD3Kg-0008MH-I4 for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 04:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Oct 2018 08:07:02 +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.153984997532047 (code B ref 32850); Thu, 18 Oct 2018 08:07:02 +0000 Original-Received: (at 32850) by debbugs.gnu.org; 18 Oct 2018 08:06:15 +0000 Original-Received: from localhost ([127.0.0.1]:56113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gD3Jv-0008Kp-10 for submit@debbugs.gnu.org; Thu, 18 Oct 2018 04:06:15 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:49351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gD3Jt-0008Kc-Cm for 32850@debbugs.gnu.org; Thu, 18 Oct 2018 04:06:13 -0400 Original-Received: from [192.168.1.101] ([213.162.73.189]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfzEP-1g1HCL30MP-00NPMN; Thu, 18 Oct 2018 10:06:04 +0200 Original-Received: from [192.168.1.101] ([213.162.73.189]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfzEP-1g1HCL30MP-00NPMN; Thu, 18 Oct 2018 10:06:04 +0200 In-Reply-To: <87zhvcteuy.fsf@mail.linkov.net> X-Provags-ID: V03:K1:Gxwgn4uyFLjGlMgB2wYjSsw5bP0K6ln/wN7YZFFXLwgaDEbLt2u aSY3Yfg81eTrTAPNLW92/dIfHliWhIPTsNO5pay2FfFI2QdGyhJSyHhx1FubGU1HQJ4YF+B fqMGybLLZmuiA0a3vVlNhsuNr4PsySm1tC18DV7K9ziscqyYfIPizisvwUAo6a4znp6SNSB ghB6qxw5QhLize/0Q1F7A== X-UI-Out-Filterresults: notjunk:1;V01:K0:cY43GJL+v8M=:Dwn9xI1vPME18S67jzJ/g+ jwTRCE+hsC+idOkwQBwxrqhWwFnfjxhg5pjRecDDaREeDdGEAppLCga2JNRm8Q2r123hJK0cI HUiWBw+ojsa6EPVbcet+v2HHJCNHI87lLzytMsXrRdg+3F7vpSj3mwBBwhF9pRSaCHWqsdCeE 6vCMJ3VUFP7NK0yz4W6bXtNA+A4dyc79LQ44glgU6AM8EWP97So4FX0zvW2CKZPltL3StZqtX GEE0z09zbmQwVcOc6sUqKIxN0NbWeTsenF1FyOb9IAbUe7qxMmKwFdAmRTwek6GRee8g+J3j9 3K7aN9wxFRc3bcQSVxQz8AxzoU70kv5XnPPB84MCrmK8CgrYTI10T8eO1eD5/yBhy8/IZnX5e R3RZQML6U5+xhzC8fIapIatdGzcpHkAo04ZskpjMLTTlPWbiMLyCDQm0f7o5Hsd8XbFzaPnLB kS/ukc0/8QuXEf5sT5Iu+4lmbkKEZlE3re8LJ/4HkE7+/pHuT7EDeGXgf2Xa36N/vQKWlcNIJ fcE6Om3YGW0z74bCNjAX7saCopo7YUFqji33RmGnhJbPc8Vosp2zIjw+wuqGoI/aq9JeptLlY yMnID1qQGRCJBZhWEidJau/XXNPLXBjI/zRxC1QL3Jmy9kDK7luISC9BKPoLtlnr41RuRknDc +vFAXJJg+kLNntkwnlE1fmtcGCfQtnHaypKuUy3tq72ZtVLOZe9SbbamiW0vGn2p/PlO7alt8 omS0mVeFf0MBuFGUTIGYMU/qhp/m4CG4Iy9QtD4OGCXQcd8dCj2t5mgrTK61V+8OLX3SVQ3m 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:151365 Archived-At: > When testing the previous patch, I noticed that killed buffers automatically > disappear from prev/next-buffers lists, so there are no # remains. > Is it handled by code in kill-buffer? 'kill-buffer' calls 'replace-buffer-in-windows' which, if the window doesn't show the buffer, calls 'unrecord-window-buffer' which removes the buffer from the respective lists. But 'replace-buffer-in-windows' handles only live windows, it can't look into window configurations. > What do you think about creating new functions to convert the existing > states from non-writable to writable and back? Then in the same session > it would be more optimal to use window states with buffer/mark objects, > and states to save to the desktop could be serialized by such functions. It would be interesting to have such a thing. One could use it to handle conversion of non-writable objects to writable ones (I always wondered how desktop would handle non-writable values in say 'dedicated' or a window parameter) and back. But we don't yet have a sufficiently reliable mechanism for providing a serializable value for a number of our objects - in particular windows and frames. martin