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#32825: 27.0.50; Deterministic window management Date: Wed, 21 Nov 2018 09:19:48 +0100 Message-ID: <5BF51524.6060006@gmx.at> References: <874leeaiah.fsf@mail.linkov.net> <5BE582D4.8010201@gmx.at> <874lcok62x.fsf@mail.linkov.net> <5BE7EE09.3020003@gmx.at> <87pnvbpejc.fsf@mail.linkov.net> <5BE93DB5.8070804@gmx.at> <87wophvpag.fsf@mail.linkov.net> <87efbprc1h.fsf@mail.linkov.net> <5BEA9577.1080204@gmx.at> <87sh047dzh.fsf@mail.linkov.net> <5BEBDDE6.1030701@gmx.at> <87sh03jjxm.fsf@mail.linkov.net> <5BED388E.7030506@gmx.at> <875zwyuicg.fsf@mail.linkov.net> <5BEE8587.9090702@gmx.at> <87bm6ntjuk.fsf@mail.linkov.net> <5BF12FE8.6010400@gmx.at> <878t1q2dny.fsf@mail.linkov.net> <5BF285AB.9040704@gmx.at> <87h8gcy95d.fsf@mail.linkov.net> <5BF3D494.90607@gmx.at> <87ftvvw93d.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 1542788350 19052 195.159.176.226 (21 Nov 2018 08:19:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 08:19:10 +0000 (UTC) Cc: 32825@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 21 09:19:05 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 1gPNiy-0004rU-VQ for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Nov 2018 09:19:05 +0100 Original-Received: from localhost ([::1]:37757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPNl5-0004ip-I6 for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Nov 2018 03:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPNkw-0004iE-Lp for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2018 03:21:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPNks-00009j-NY for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2018 03:21:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33504) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gPNks-00009M-Ie for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2018 03:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gPNks-00042V-D3 for bug-gnu-emacs@gnu.org; Wed, 21 Nov 2018 03:21: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, 21 Nov 2018 08:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32825 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32825-submit@debbugs.gnu.org id=B32825.154278840615420 (code B ref 32825); Wed, 21 Nov 2018 08:21:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 21 Nov 2018 08:20:06 +0000 Original-Received: from localhost ([127.0.0.1]:37759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPNjx-00040e-Rd for submit@debbugs.gnu.org; Wed, 21 Nov 2018 03:20:06 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:33299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPNjv-0003zf-Gx for 32825@debbugs.gnu.org; Wed, 21 Nov 2018 03:20:04 -0500 Original-Received: from [192.168.1.101] ([213.162.73.56]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lfppu-1ffttw4ANW-00pNaA; Wed, 21 Nov 2018 09:19:55 +0100 In-Reply-To: <87ftvvw93d.fsf@mail.linkov.net> X-Provags-ID: V03:K1:KpdphrZmXmFWqCRsiiH/nnbXXoMRB/MQWLenrSsFpR16mUJU2DZ WYhR63wl6XXClMnWKR0pDyokLkwxSyozX6wmHpZHYMS99fr32lHEjTuX3x3yciWKnx7H0fq u4gyKJ76b2+wVVKUzeux0Xh5A9E0lIoelpzFo58J/D4vnsKHW5bHHt3dTZSi2d2D1eMrGVw QjQDUk3vIvLA3iEuBmxBQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:TicQgtvhLLo=:BGcHhrQ1MuVLAeTeJ9KK3N wmfVXryU4sO/hV8ZKpYbwYt1a2VLwUVUfebtC4N8SW2BxujTqRn+ghw81OlOkxBwxde3Zbq1e HwV/2dF/xAsKTA17L64qxch/jP0+AJp12SHiDW+v+YcUjNXs+w2yHoXDgy1GGrmB6JE/ecIRA rCOvivYVn+1ZLK7OeSskgvPWf1Fmkd22JKajmw+jN+qNJKdzgTLM1HaXhabIFnLFzrlfALIrX id4ByfRgyvvDqo6p7E6oy7kTh69SHD5pd7cwmnNI/RWepfxo3s5y1PtPxlJ+RVBUM1geuDBc8 p99kBvp74bl9/jmTsOGAFVgs5oiRE2gNValAaxzU8swqjISqcMVH+tPknTZ8e9aRx9HdHz/9b 9SXEe6n44tJlqQzXAXMVNAXhWPieCCgf7gCi9FlcXnbfweyroG2HXyrRQazLNQDI1MDOJTwBf o/MKbwoyBtK/jw5Z0fqNp3rXiXE89egwh9iALS1um7MzHWbVmsvh87g21ch4FUkHxsswD/+7A ib0jBUWGXLoH4PWdOOlPRpSlvwep3B29ojm8eyx++c+ztyCO7YnzGrpdSWxEWaty+dLP0yOaU xj8y1/sRZbQ6CtQMlfHYM78ZCfm8THKWcgjZ9M7T+WyRB1KvuMUxCYR7hSyOr2aVXH7npzgBP cg8tRYzbZGUAdVODU4mbql1cHUr3l+QUI018kfHfZkUz5z0LwpjOWDR0IfUPw7mO8k6QWjP0d YGB5m1kmX57UPI9GAZ+CHiZCubbC76P/Orsf1wMxAnZ5TyJLfivB7dSYvY29HSYyaqoIKLIL 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:152622 Archived-At: > I imagine a list of prev/next-buffers as the tab-bar: > > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] > prev-buffers current-buffer next-buffers > > Using switch-to-buffer adds a new buffer after the current "tab", e.g. > > [buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E] > prev-buffers current-buffer next-buffers So far the buffer shown by a window does not appear in its lists of previous or next buffers. > But displaying a temporary buffer could add a "tab" to the end of the > tab-bar, this means at the end of the list of next-buffers: > > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer] > prev-buffers current-buffer The problem with this approach is as follows: The list of next buffers is usually empty because it contains only the buffers visited while navigating the list of previous buffers backwards in time. It's main purpose is to revert any overshooting during such navigation. But this means that when you add your temporary buffer to the (usually empty) list of next buffers, overshooting while reverting the overshooting will get you to that temporary buffer immediately. In your example I would first show buffer-C then overshoot and show buffer-B. Reverting that gets me to buffer-C and overshooting once more will get me new-buffer immediately (because buffer-D and buffer-E typically do not exist). > After exiting from this temporary buffer, it could be kept in the > list of next-buffers: > > [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer] > prev-buffers current-buffer next-buffers > > Then returning to prev-buffers (e.g. with kill-buffer) will not visit > this temporary buffer. But display-buffer-reuse-window could look for > a previously displayed buffer in the list of next buffers. The main purpose of a window's list of next buffers is that of undoing a 'switch-to-prev-buffer' step. I have no idea which consequences your proposal could have apart from the one I sketched above. I'm already no great friend of If there is no recent invocation of `switch-to-prev-buffer' that can be undone, this function tries to show a buffer from the buffer list of the frame WINDOW appears on ... but this comes from an attempt to model buffer switching like 'undo' does. martin