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: Thu, 22 Nov 2018 08:41:47 +0100 Message-ID: <5BF65DBB.6030803@gmx.at> References: <874leeaiah.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> <5BF51524.6060006@gmx.at> <875zwq7zql.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 1542872475 13640 195.159.176.226 (22 Nov 2018 07:41:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Nov 2018 07:41:15 +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 Thu Nov 22 08:41: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 1gPjbq-0003RE-Lj for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2018 08:41:10 +0100 Original-Received: from localhost ([::1]:44543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPjdx-0005z4-AR for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Nov 2018 02:43:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPjdp-0005yZ-Kc for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2018 02:43:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPjdi-0003Xh-So for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2018 02:43:10 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36201) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gPjdd-0003Sb-UY for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2018 02:43:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gPjdd-0001U4-QV for bug-gnu-emacs@gnu.org; Thu, 22 Nov 2018 02:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Nov 2018 07:43:01 +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.15428725265620 (code B ref 32825); Thu, 22 Nov 2018 07:43:01 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 22 Nov 2018 07:42:06 +0000 Original-Received: from localhost ([127.0.0.1]:40456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPjcj-0001Sa-UX for submit@debbugs.gnu.org; Thu, 22 Nov 2018 02:42:06 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:43019) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPjci-0001Rv-C6 for 32825@debbugs.gnu.org; Thu, 22 Nov 2018 02:42:04 -0500 Original-Received: from [192.168.1.101] ([212.95.5.41]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBJF3-1gG8iU3HfB-00AFQn; Thu, 22 Nov 2018 08:41:55 +0100 In-Reply-To: <875zwq7zql.fsf@mail.linkov.net> X-Provags-ID: V03:K1:dRF2ciFO85FFUbLPE4k38S4f6jUDC7Jb/MPVk1VaWTPi8jNDWn6 4fzOkEiwjkcJgk9RyREheEIE4Xl40vTAS9FBVBrHet/bt8Ff8nTUNHWqWEdInS+6+T0PTfg Vsub9IUHnbwwWcGMYTHaxla79CbxS/VtLqTadesFX8OGpHpDqso6P5Ud4V34U5pZuKqUR35 V54Zv7mg6pqkZS7wUVr8A== X-UI-Out-Filterresults: notjunk:1;V03:K0:ddKkc2HqEDE=:RvtVem+ebCYj6/te6FqLIl FVnAUCvTQ9zkmtR33iTd7uqvsFFpTnA6ulDaA0zL+gt9/JDJ1D7JQEU2DgHaj0n6ba4Yt46mp l6uSkpIirVQLvLxM+W2E+21ztQ5d42z6Fc++mh6e+mOK+UJau5kWXUUplaFncuUC+yc+8gbI+ r/9uVqd5XWvghty8jKeiWp6bBS82z9cz26Q+5FyHJV0Yw8babqzUqEbI5bTsSuLwZXGVecHD6 S4Ht/u9AVlQCzytScIUeEFy0Vu3xTMI2rZIR7/um74BOM9EHOyatUozg2N12jaNZxGFhp8rPf K7sLY+sH939mlun8keHlWgPKGhyKJwz7eCQfEX+2oMmAXoQbkuDGlqHQCwCHo1bZIzb1wPxhe blCsQSxfzsZXTALzNERHt6n9xyStownVy2gkuV1V+hqzg79kRFEWQBI9o17bls0AUOWwPRO32 6H7E+vV0QSHr/Vvu8gaRbRt1ES+b2qSjXPdTBi88eIQWt/yGnVNjKvNRkFv33zGnk3ovLbgAD 0DpzW2aC2uAUmIRnDLd+EQdjD+aib5KmZJKCt38EFcawHgwLMCDA3IHFIhLF9+39IcTlSHKoT GZAnFRTIHvqSWGOf5EvXApTyMNFe6V3+uHKnamAAhaEjjXEh28anGeF4GEl/nv3AjEDk3LSM8 JAe4K65JtgAFLiVTQUt6pCXK7zjkJUSilNMArzq1YLiNtCNudyfD9VAiSuEpMRGK4O7bBebLN bYd9KlsByGZxTFwIchjJTEoHr8sp7Q7BYXPnocOc8ACorTYiIVDGD13FYjd1EEIsAvIl9VzJ 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:152663 Archived-At: >> 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. > > What buffer does it show now in this case? Is it a more predictable > buffer than would be in case of a previously displayed temporary buffer? Currently we remove the buffer in question (*Backtrace*) entirely from all buffer lists so it isn't found by the switch-to-prev/next-buffer routines, the list of next buffers is usually empty and it will do ... >> 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 ... > > And this is usually some random unpredictable buffer. Correct. But we cannot well go to the end of the list of previous buffers instead. That list could be even empty. And traditionally Emacs chooses some random buffer here although the order is a bit determined by previous 'bury-buffer' calls. >> but this comes from an attempt to model buffer switching like 'undo' >> does. > > undo/redo is a good analogy. Unfortunately, undo/redo does not stop either where my intuition would want it. In particular, I can't tell it to "now redo things until you've got me back the state with the maximum of changes of the existing code since I started editing this". There's some fuzziness missing. Maybe some snapshots of my past editing activity ... martin