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: Mon, 19 Nov 2018 10:43:07 +0100 Message-ID: <5BF285AB.9040704@gmx.at> References: <874leeaiah.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> <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> 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 1542620528 7072 195.159.176.226 (19 Nov 2018 09:42:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2018 09:42:08 +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 Mon Nov 19 10:42: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 1gOg4B-0001iy-7X for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Nov 2018 10:42:03 +0100 Original-Received: from localhost ([::1]:54950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOg6H-0006zq-TF for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Nov 2018 04:44:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gOg6A-0006zW-W5 for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 04:44:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gOg65-00088s-VC for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 04:44:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55416) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gOg65-00088k-Rf for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 04:44:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gOg65-0006eo-Nq for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2018 04:44: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: Mon, 19 Nov 2018 09:44: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.154262060225534 (code B ref 32825); Mon, 19 Nov 2018 09:44:01 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 19 Nov 2018 09:43:22 +0000 Original-Received: from localhost ([127.0.0.1]:59674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gOg5R-0006dm-TJ for submit@debbugs.gnu.org; Mon, 19 Nov 2018 04:43:22 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:53099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gOg5Q-0006dZ-Ap for 32825@debbugs.gnu.org; Mon, 19 Nov 2018 04:43:20 -0500 Original-Received: from [192.168.1.101] ([46.125.249.53]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M2ts6-1fYMNi0HdG-00shfg; Mon, 19 Nov 2018 10:43:12 +0100 In-Reply-To: <878t1q2dny.fsf@mail.linkov.net> X-Provags-ID: V03:K1:nDuq4yKz6h4rOr4VKXsnRL91Q2xCdd7dLkDzIqYujlgyh9XuHCu EVPI7T0/7z4+YVBvALIpm7EA8kAl+LMlgHav7B8024595aC+SzdaHLyAVmTTq5u/T5DKe5a fNKR8aDyImeg1/OPPQUYWVtKuUVe/7pHaii7ARBxXen99SXUGL3SOl6HnMBV0j2k7XSG+hN va99+FZEM1v/q/QLYQ2cw== X-UI-Out-Filterresults: notjunk:1;V01:K0:2PkAQf1/D3s=:1yTOHV9onRs5N9VoPojrIg CDJ2zSgZysVZpO+UQ0M9DgfZc3PE8DjEl7gqTbRZ65GtkBpgrdF8iOFXFkQvqVjlPj/eRFKLS CAdEslwuimAz7aBNKiLB1BhyULB7W8QYMwFpkok2cmIKIDPGvp79QFxe7l/hrxaz7APLUJ4Kf i3HtjDbquVPLXgqWGOoIMB110ASrE0EFcCKlG8L85d8cRsFwfTrtBpcUGttnfn+Ladl99LkoK fqfBiefHxCLbXQApTQki7T4/eMo1toKy8E2XSew3DRUdZ7EUD98fnikU1agjZb0INBW2ByDi2 f6Y+yAuKqGAcJXeHQyoNCuEcpFejWoReJpj4s8T+NVsh+IHI9k/ZDBVI/Vzfj66vpOId2cPjl gC2GmOUWQw+H87NTYTfJ8JeuOgoNrDIxMPx8DTZEttykSRMKb0o+EeXsbaNVKf7auBLvc9vny DwYkQOWaYUB0XWWip+3NEDyTGxB4u6bckzapbntJoLjGoybzUouQC8uHpmJhSgLNfJVCUk1rI C1sCrAMxHGScKfJqTsDjIab7RNCOk4StnxLPbVFhedScj+dJ96WxheA12DBp8EnEbVJe9TMUu qfiatirGCxcaQXauqCKTq43wDqAGJPTaZpur5rilGpo0pvMgGOpeDhbLe54R46pqlCb+WL6nK EyvfqKTFGOzjT8tXQuRpNjeq5KgDsiRcdRUIEzA9I12AGx0xB+n0c9E7kyeIQ67C1H8AteY3J A16HYG1DSSvuom16HyTGtdzKk69dp4iPIJNF/0OlAV0uRzpvWeDUV1GXgnkrMgxNysJWDMHI 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:152526 Archived-At: >>> Then maybe better to add such buffers to the end of the prev-buffers list >>> or to the end of the next-buffers list. >> >> We have that option in 'debugger-bury-or-kill'. Do you mean to >> generalize it? > > Yes, it could be moved to a new alist entry. And act like a time-bomb via a window-parameter (like 'quit-restore')? >> OK. What do you want to call it, 'windows-to-examine'? > > Too long name. Maybe better 'try-windows'? Or 'reuse-window' > if this alist entry will be used in display-buffer-use-some-window. 'try-windows' sounds too active for an alist entry - we would have to use 'windows-to-try' instead. And let's avoid 'reuse-window' in this context - it's too ambiguous. BTW we might also want to add a similar entry for specifying the window we want to split (which means we could easily generalize 'display-buffer-below-selected' and 'display-buffer-at-bottom' without having to add new action functions like 'display-buffer-at-top' ...) and should reserve an appropriate name for that. >> Shall we make it a list of function/frame pairs defaulting to >> >> '((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0)) >> >> where nil stands for whatever >> >> (or (window--frame-usable-p (selected-frame)) >> (window--frame-usable-p (last-nonminibuffer-frame))) >> >> returns? Or do you want to control the DEDICATED and NOT-SELECTED >> arguments as well? I hope that 'get-largest-window', 'get-lru-window' >> and 'get-mru-window' are 100% compatible wrt their arguments but >> haven't verified that yet. > > I thought it could be a list of window types to try in the specified order, > for example: > > (try-windows . (mru lru largest-visible largest-visible-and-iconified)) ... and lru-visible, lru-invisible? BTW we could allow it to specify using windows dedicated to another buffer as well. >>> I don't understand what an alist entry you mean. Or you mean adding >>> a new alist entry like (default-window . mru-not-selected)? >> >> For example. To provide the 'windows-to-examine' sketched above you >> wouldn't want to specify an action function too. > > But where this alist entry should be customized for all action functions? > I guess not in display-buffer-alist that specifies specific buffers. > Then where? Maybe, in display-buffer-base-action with nil action and > non-nil alist that will be the default alist for all actions? Anywhere. Why should we impose any restrictions here - either for the user or for the application programmer? martin