From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#32825: 27.0.50; Deterministic window management Date: Thu, 15 Nov 2018 23:43:59 +0200 Organization: LINKOV.NET Message-ID: <875zwyuicg.fsf@mail.linkov.net> References: <874leeaiah.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> <5BED388E.7030506@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1542318733 13695 195.159.176.226 (15 Nov 2018 21:52:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Nov 2018 21:52:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: Michael Heerdegen , 32825@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 15 22:52:09 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 1gNPYT-0003LB-Ps for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 22:52:06 +0100 Original-Received: from localhost ([::1]:40908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNPaa-0007Yt-6B for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Nov 2018 16:54:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gNPaP-0007Yh-JH for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 16:54:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gNPaM-00037I-Fj for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 16:54:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50265) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gNPaM-00037C-CO for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 16:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gNPaM-0007P5-8F for bug-gnu-emacs@gnu.org; Thu, 15 Nov 2018 16:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Nov 2018 21:54: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.154231879028399 (code B ref 32825); Thu, 15 Nov 2018 21:54:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 15 Nov 2018 21:53:10 +0000 Original-Received: from localhost ([127.0.0.1]:54523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNPZW-0007Ny-2p for submit@debbugs.gnu.org; Thu, 15 Nov 2018 16:53:10 -0500 Original-Received: from ladybird.maple.relay.mailchannels.net ([23.83.214.98]:40751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gNPZU-0007Np-Cb for 32825@debbugs.gnu.org; Thu, 15 Nov 2018 16:53:08 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4392F5C3DD7; Thu, 15 Nov 2018 21:53:07 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (unknown [100.96.11.179]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id F16805C3E58; Thu, 15 Nov 2018 21:53:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Thu, 15 Nov 2018 21:53:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Chief-Callous: 6ed8f0845d38dfae_1542318787096_689840389 X-MC-Loop-Signature: 1542318787096:3682614475 X-MC-Ingress-Time: 1542318787095 Original-Received: from pdx1-sub0-mail-a77.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a77.g.dreamhost.com (Postfix) with ESMTP id 88CA680286; Thu, 15 Nov 2018 13:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=/aaz9rhBFvNpyeYrlUaY4/p5ss8=; b= Rvlhp7Q2rilvHVpNeg/+nf9pYBMYRGZPOaxSAQPLjhfmJHtq3wSnNdS/bNC2pr4L KqfrGPrCykcLZzGER5pUCN6j5qQZO4mA3j6fLr+Zl5s8XuTC7xtqpwTxHVzVtOx6 8peVEnwsnM4AbtcSRK7ZY842sUvnSSE4vZXgLJgWFuw= Original-Received: from mail.jurta.org (m91-129-107-244.cust.tele2.ee [91.129.107.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a77.g.dreamhost.com (Postfix) with ESMTPSA id A42A080285; Thu, 15 Nov 2018 13:53:02 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a77 In-Reply-To: <5BED388E.7030506@gmx.at> (martin rudalics's message of "Thu, 15 Nov 2018 10:12:46 +0100") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrleehgddugeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdejrddvgeegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddtjedrvdeggedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehruhgurghlihgtshesghhmgidrrghtnecuvehluhhsthgvrhfuihiivgepud 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:152435 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? The need to skip. If the original window was too small to split and display the buffer in a new window below, then if some existing window is reused to display the temporary buffer, it's understandable for the user why that temporary buffer is shown in the window-local tab-bar. At least, then the user will see in which window the same buffer will be reappear again - in the same window that shows this buffer in its window-local tab-bar. >> 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. I agree. > 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'). The second time when the buffer is displayed again in a previous window is deterministic. But the first time it is non-deterministic - it's displayed in a random window. At least, the user can't predict the window where it will be displayed - thus the surprise factor. With get-mru-window instead get-lru-window the place is more deterministic because the user usually remembers which window is mru. >> 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. Right. Neither lru nor mru should be used to steal existing windows from users to show temporary buffers. Only new windows should be created below or on the bottom. But my complaint about get-lru-window is that it prevents me from using more than two windows. When I create three windows or more, then get-lru-window always selects a wrong window. Is it possible to change get-lru-window to get-mru-window to allow using three windows and more on the same frame?