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: Tue, 20 Nov 2018 10:32:04 +0100 Message-ID: <5BF3D494.90607@gmx.at> References: <874leeaiah.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> <5BF285AB.9040704@gmx.at> <87h8gcy95d.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 1542706274 1488 195.159.176.226 (20 Nov 2018 09:31:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2018 09:31:14 +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 Tue Nov 20 10:31:10 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 1gP2NB-0000IK-KH for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2018 10:31:09 +0100 Original-Received: from localhost ([::1]:60960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gP2PH-0002Oy-Ev for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2018 04:33:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gP2P4-0002Mp-Nf for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 04:33:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gP2P1-0001sI-0S for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 04:33:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57362) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gP2P0-0001p2-9O for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 04:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gP2P0-0007P7-5t for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 04:33: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: Tue, 20 Nov 2018 09:33: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.154270634028407 (code B ref 32825); Tue, 20 Nov 2018 09:33:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 20 Nov 2018 09:32:20 +0000 Original-Received: from localhost ([127.0.0.1]:33387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gP2OK-0007O7-9U for submit@debbugs.gnu.org; Tue, 20 Nov 2018 04:32:20 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:39723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gP2OI-0007Nu-Mo for 32825@debbugs.gnu.org; Tue, 20 Nov 2018 04:32:19 -0500 Original-Received: from [192.168.1.101] ([46.125.250.103]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfVU3-1g4L8T1M0B-00P8n7; Tue, 20 Nov 2018 10:32:10 +0100 In-Reply-To: <87h8gcy95d.fsf@mail.linkov.net> X-Provags-ID: V03:K1:3GEWRnTwAE0s/JIlEGbx+V7tdf5rTIFc50D7cFpXsGB2pfV/gw0 QXlMGB2+M6B1qWWr1r/htz/X9JVLL4sPhEKlZVvTE9jMUIEGduQ+91BMQsC/0t9io4BZxkR twO4sQSQ6qcYfksKVbZRb1q+jvxw8n3wE3pJnhZ7lQslcuXyH7zxQMLmQz6kWiNv63tafk8 VTAnt4eVry5olsQfQfNgw== X-UI-Out-Filterresults: notjunk:1;V01:K0:HhMugyipJS0=:LnahA0L4XgUSod39bj0DsV /sDE46E6RH999PiS7QRNSBzj/P+dXNFDTtHICetc7BfQVIj1ofGBhG3Ihkkwb686bValyg4YT /9OE1ViJMbpeHZF81qpD+nVYBZGc1jkfDhhfio64mRVKL7z2TLzx9qR0rd+B2uhXGgZ2THdGx fXbiynhMBaQ7W6ucfQOyJ5MiXvJxJKaH2rpwne9/muBavsOtlyHmAUVLVW9s/hIhw41/ViEEc 6/spc4gKujo1dcBQjjtThUYbO8QVCv9m/eZbA9CtFe/QbZ+ldOPuI7KVLERm5T+LCyw9trK1e OwnHWjI5ly6v73RmCHkPCDtKcLAT9/4WPHaIWl+fOuutB/xOn/mITjLqMsc31rlzGFvxF+h2p 2yOA/BEQs6+WdDz4YCYLOhGIYaEvgGnOGX0svn8WTAkiO5IsqC5/TKysdQ+R9eTh4KiUXXbqN iPsQCamLXBIZ0IfQPalFjWHcv7L52ihO0mL5uSQwnBvXv0CAATHOhrHK/twysbzVx6W+ZU62A OMgfn/AJ0hby8tsk7RLf2tM5cbyo/UZIvtoEC3ucO+AmJTt1bbAMGScG+PZGiDguTiDFrjMgf dPxyyKA+XG7g8Y/mRf4TMqUQvTDEmUqJP0tQBlSrajKF7Df0vdpPJvYaiH8LF2zSoP/8qApL+ KLCvG1UxmzlKq/tlUTpP/qr+D+eI86g+xNXVc4wERq0W6XEYEfJATe1k6EbxgkICt0lWZ+dxQ udX9AatBdJ2IC5aDK8jhqDvHHEE4Bf/vm0EYssLHeHfxyVHcyw/g8b1dAYBdF4knB4R22OH9 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:152563 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')? > > I don't understand what would happen with this. An alist entry describes what should happen at the time a buffer is shown. 'debugger-bury-or-kill' describes what should happen when a buffer is unshown, something which may happen long after showing it. So we have to remember the thing to do at unshow time (probably in a window parameter) and make the unshow code aware of it when it runs. >> 'try-windows' sounds too active for an alist entry - we would have to >> use 'windows-to-try' instead. > > If you want more declarative names, then what about 'candidates' or > 'default-window'. Both could apply to any action function: I'd prefer something that can be attached to specific action function like 'windows-to-use' or 'some-windows' for 'display-buffer-use-some-window' and 'windows-to-split' or 'pop-up-from' for 'display-buffer-pop-up-window'. >> 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. > > Maybe use names like in WindMove: action 'display-buffer-in-direction' > and an alist entry '(dir . right)' where the default is '(dir . below)' For example. The question is whether any such 'dir' should apply to using, splitting or both. That's why I'd rather include the direction separately in the 'windows-to-use' and 'windows-to-split' entries or whatever we call them. That is we have to decide whether we make one entry dedicated to each buffer display function or make entries that apply to more than one such function. We have the latter already for the 'side' entry and I'm not sure whether I like it because it's not always clear whether two action functions are mutually exclusive: Now hardly anyone would ever want to _facultatively_ display a buffer in a side window or an atomic window. But when we want 'side' to refer to where a new window should be created or (re-)used I'm not entirely sure. I know that 'display-buffer-below-selected' and 'display-buffer-at-bottom' both implicitly fix the side (or direction) for both, using and splitting, and that's OK but maybe not all applications might want it. martin