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, 15 Nov 2018 10:12:46 +0100 Message-ID: <5BED388E.7030506@gmx.at> References: <874leeaiah.fsf@mail.linkov.net> <5BE00EB1.6090107@gmx.at> <87sh0fxkih.fsf@mail.linkov.net> <5BE154F5.4050902@gmx.at> <87r2fxsvl5.fsf@mail.linkov.net> <5BE2AF02.40909@gmx.at> <87sh0cva5h.fsf@mail.linkov.net> <5BE3F981.8000002@gmx.at> <8736sbmdtv.fsf@mail.linkov.net> <5BE54FBE.306@gmx.at> <874lcqmu6u.fsf@web.de> <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> 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 1542273141 827 195.159.176.226 (15 Nov 2018 09:12:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 09:12:21 +0000 (UTC) Cc: Michael Heerdegen , 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 15 10:12:16 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 1gNDhA-0008W3-9C for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 10:12:16 +0100 Original-Received: from localhost ([::1]:37575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNDjG-00011d-6y for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 04:14:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNDj3-00011A-H6 for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNDiu-00052A-0Y for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48734) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gNDis-00051Q-Uj for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gNDis-0007wx-O7 for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 04:14: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: Thu, 15 Nov 2018 09:14: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.154227319030455 (code B ref 32825); Thu, 15 Nov 2018 09:14:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 15 Nov 2018 09:13:10 +0000 Original-Received: from localhost ([127.0.0.1]:52985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNDi1-0007v8-OL for submit@debbugs.gnu.org; Thu, 15 Nov 2018 04:13:10 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:41653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNDhx-0007ua-9F for 32825@debbugs.gnu.org; Thu, 15 Nov 2018 04:13:05 -0500 Original-Received: from [192.168.1.101] ([212.95.5.247]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBFUT-1gD16Y2mA9-00AHCt; Thu, 15 Nov 2018 10:12:55 +0100 In-Reply-To: <87sh03jjxm.fsf@mail.linkov.net> X-Provags-ID: V03:K1:1/eFhGwzvaloNCRIkMDnGZTybHu0Ti5O9YuPLTrR7MuQCfaRI4V mHh9HYPE2EBI2cPls9CifIH6QY33Lvw6EJj68CIJw4ZoDJ/ajaue3spnvGQLAiaewY65ulB jWweggbuvctnLGSMpJkCBMqikhHicmweQAahAISkST1tPNRiGBaShjdiH8J9rpxj7d7nlIc auLRfWIlt7Zm0za9jJ8cg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0X7/ga4xMBw=:kEUFx50jtDtsvSniBomOsK 6Ym3n3ue/DSB4PfgiuIzDpCy0RyCGoC09PWonNeM/LgV5bxe88fAclOONDHwQbBa5lHDoA/Lq BMOtrAPcpA8cKEt2tjcqK25biHM2eMH1iUuyisTnxTCEB5r25QC8QFKnnq5DFZhUY9bsqolvW rqXXyUwnuVqunGtTkO3xYQ/DNAocE0b2AWzzx+ckITwLVhPQG6GfHDVFilcWtOnoWK3WWhBkp Mig7ePVC/UIPaNNyToL5rtgZcVvR8e19nijgtsY8zT+Czex879MPkL4RuHYWY5Jvh6B9aw9IM NvqgAtoseyPMaFf4sTT56PXHN0mIa7w28Eq64zdfjOjE4tXqoW1QSb1qKkoc/OnaPHToalhSu uvpX4Lx8rVhaJwq2BrAjZKnnutNXMwYyBWfB7kUDb6NYxarNS1TpYeodE1c4BN11hOo8xwU6r z8GNjuEFg1pG3oLAgPIO4FgiqA87qNCio0/mtoYRdCMn5o5f1jOmDUCI6d7F86qnm7oHKebDN VbkH18wVDHK6GE7/Mh2UHCOIA3mxciC6f98laLecp8WEVCoo7wGdCROJwzdbH7fvTTj3BTS9t 1iYD3iTfTvpkTrrCSo8FqDaogsoEb3GeFtmCgGiIzyC+/Ia8/sa65mRLHOZrE4gndnEcNawvm zaJe0Qn0JwhRlTcbQ2j1yfUyG9OQ9uKAlt/e3Sh5yeOC2yv7yFH/RvMpNTIzTq/G1vvqVT28y wjZC+kd/q3N0Mhik8Dwng1gDopQIlFRMDCSGwETnF2feManvH1QwSjyva0xk2/Ryc6pCADbn 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:152406 Archived-At: > 'display-buffer-in-previous-window' searches the buffer in the > prev-buffers list that 'switch-to-prev-buffer' might want to skip > (I still doubt this need). The need to skip or the need to search? > I proposed to generalize display-buffer-in-previous-window > to avoid duplicating code like in debug.el that uses > debugger-previous-window, debugger-pre-previous-window, > debugger-previous-window-height because the same feature > is needed in other packages like edebug.el. > > The same feature is needed also for next-error to display hits > from different buffers in the same window. When a user can always make a new window there is indeed no problem: place or reuse the window below the selected window or on the bottom of the frame. Both approaches are sufficiently deterministic in their choice of a window. But as soon as a window must be reused and the selected one is at the bottom of the frame, it can become quite difficult to assure that a buffer shows up in a deterministic location. This eventually gave raise to the idea of introducing 'display-buffer-in-previous-window' (together with the fact that a window's previous buffers then became easily available via 'window-prev-buffers'). But 'display-buffer-in-previous-window' works only when the buffer is (1) kept alive while not being displayed and (2) is kept on the list of a window's previous buffers. We could add the _names_ of buffers previously shown to 'window-prev-buffers' but that would not allow for auto-removing entries when a buffer gets killed and also fail when buffers are renamed. So generalizing that function might be non-trivial. > Or better to obviate the need in all this complex special handling > simply by removing the get-lru-window rule in the default action, > thus replacing it with get-mru-window. When people work with two windows simultaneously, the mru one is usually the "other" window they work with, maybe showing the same buffer at a different location. I think it would be a bad idea to punish such users by reusing the other window for showing some temporary buffer instead. martin