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: Wed, 17 Oct 2018 09:31:37 +0200 Message-ID: <5BC6E559.3090000@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> 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 1539761445 18206 195.159.176.226 (17 Oct 2018 07:30:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2018 07:30:45 +0000 (UTC) Cc: 32850-done@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 17 09:30:41 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 1gCgHw-0004dA-1F for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 09:30:40 +0200 Original-Received: from localhost ([::1]:34247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCgK2-0003E8-L5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Oct 2018 03:32:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCgJO-0002Xi-Eh for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2018 03:32:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCgJH-00035T-CQ for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2018 03:32:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50079) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gCgJH-00035M-4b for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2018 03:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gCgJH-0006RX-1U for bug-gnu-emacs@gnu.org; Wed, 17 Oct 2018 03:32:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Oct 2018 07:32: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-done@debbugs.gnu.org id=D32850.153976151424723 (code D ref 32850); Wed, 17 Oct 2018 07:32:02 +0000 Original-Received: (at 32850-done) by debbugs.gnu.org; 17 Oct 2018 07:31:54 +0000 Original-Received: from localhost ([127.0.0.1]:54332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCgJ7-0006Qf-Qk for submit@debbugs.gnu.org; Wed, 17 Oct 2018 03:31:54 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:60761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCgJ6-0006QR-6s for 32850-done@debbugs.gnu.org; Wed, 17 Oct 2018 03:31:52 -0400 Original-Received: from [192.168.1.101] ([212.95.5.87]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzHZ7-1fZ8PB0ofx-014UMG; Wed, 17 Oct 2018 09:31:44 +0200 Original-Received: from [192.168.1.101] ([212.95.5.87]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzHZ7-1fZ8PB0ofx-014UMG; Wed, 17 Oct 2018 09:31:44 +0200 In-Reply-To: <8736t57jcs.fsf@mail.linkov.net> X-Provags-ID: V03:K1:Ye2G7DJe8OP69S3+w82H4Gq2zvEDONTw/wsWhEX49DTvAJDqNZU 0KAe/vx/T/Cw70l1JaB4s0QLyfYojrQiCFFkD34ADZU/YyxXAezEsyXI4AlbFCOg8mk+o0E w4tDHJh4e5u1rR94BFBR58qaL/xKprrF3wnsEUZLC/EACDwGUEnRD8KY34Xtnq0KSgxashf goxVqwqAJeQmCTaJJcKnw== X-UI-Out-Filterresults: notjunk:1;V01:K0:E4GtksW1Ljo=:9jDkXTuMD5Cvkk/mAuGimi gI94n6J9herA4BG0OI4mcYXw48H5xjMPQMl39oTqt7YKz+Sum/l8IeJAdUjThvCcAFYzhl8QZ yS2i7C64eX4L5mfnf52xiM14gR3wuM1GgQKzJSceKydQE2C8T6qXtX2zHXog5eBqpftqGK9bW ilZOO9gf+IKKPh4RQlLtnoYql6FLTft+y8+XFGc2HR72uCn65RcFpaGPXoImZKI+hgR7FkSZb 44q4bwii4XgGWmZ5yVll5wwjM4EDhH7IGphCibf037GqJV7pnq/rer721dc0RqPkRNCQmcdNE 2/NATduKPJ0alTweDk5KU1/rl5Vi5kUrjgDmibwzCB0UUP429dgSx4hrqco5gy/nC8Uz0kSWl 8G9WrJFulLF5JienI1MVQjCJPUQy0uKMe52QrHGAyMVuyzfgHB4uAnre+2vO1dfY2qt/rnIkf v9h5gKWADr+klBePevaZp9+RD8n4oHZjwOyG1TkoCSz4+XaRdlrycyXKqo5+iUsWs586K8wV4 A5qyqyjog3TZPJVWvrGBSziQ2SafJ5wc0EOAOjIsZrDo1Q2Y7nInDNo2lRBp1T7yJ5/QYBRrE dkZqiz6fhUCipN1pMZtzTXfd83kKO8PWumijb53qpj05JuSVrsr9p/ujSO2WOghCSbgxfsg2h 5i8iTGakCdLS+VHw+3KCILc3ZJMVZkRffWEDcAa+dHsCwalfCIS8IYiHQFcKe8DR9VBQGZFif WEGXNtlpntCIJ0O97ugwlM1mdoZGuAJcZBCfFEdJYjMsTazju4r/zGor26WD40viMEvVK6sh 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:151340 Archived-At: > I'd like to make it customizable by using the existing customization in > the arg WRITABLE of window-state-get and window-persistent-parameters, > even though formally prev/next-buffers is not a window parameter (maybe > it should be, I don't know). Always keep in mind that prev_buffers and next_buffers need special treatment in mark_object to make sure that dead buffers from window configurations stored somewhere (for example in a register) get their entries deleted and can be eventually reclaimed. This is something I completely disregarded when writing the original code for navigating these buffer lists. Stefan then wrote the code to do that in mark_object. > Done, with a small change: even though set-marker is idempotent in regard > to its POSITION arg (i.e. if POSITION is a marker, it creates an identical > marker), I added a check to not create a new one. OTOH, get-buffer is > idempotent too, but it seems window-state-put never receives a structure > with buffer objects, and I'm not sure why window-state-get should always > use buffer-name regardless of the value WRITABLE, i.e. why should it return > buffer names as strings instead of buffer objects even when WRITABLE is nil? Maybe because I didn't care about non-writable states back then. But you're obviously right. Buffers can be renamed at will and in that case we might have a state with a non-existent buffer or even buffers with names switched and therefore invalid values of start or point. So yes: Please use a buffer object for non-writable states. martin