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: Mon, 05 Nov 2018 23:49:27 +0200 Organization: LINKOV.NET Message-ID: <87sh0fxkih.fsf@mail.linkov.net> References: <874leeaiah.fsf@mail.linkov.net> <87wor7uqgb.fsf@web.de> <87o9bhkeih.fsf@mail.linkov.net> <87h8h9hk4w.fsf@web.de> <87d0rvb7xg.fsf@mail.linkov.net> <87sh0rkucr.fsf@web.de> <87d0rvqf5r.fsf@mail.linkov.net> <87k1m3krvm.fsf@web.de> <87o9bf13b4.fsf@mail.linkov.net> <87d0rvkq01.fsf@web.de> <5BD57C2B.7020109@gmx.at> <87tvl3rvks.fsf@mail.linkov.net> <5BD96392.3040008@gmx.at> <87y3adakkh.fsf@mail.linkov.net> <5BDAC0ED.9030405@gmx.at> <87h8h0juwn.fsf@mail.linkov.net> <5BDC0E38.5020901@gmx.at> <87d0rl7kl1.fsf@mail.linkov.net> <5BDEB6BA.5000307@gmx.at> <87y3a8jz6v.fsf@mail.linkov.net> <5BE00EB1.6090107@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541455618 5022 195.159.176.226 (5 Nov 2018 22:06:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2018 22:06:58 +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 Mon Nov 05 23:06:53 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 1gJn1I-0001AE-N1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Nov 2018 23:06:53 +0100 Original-Received: from localhost ([::1]:37809 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJn3P-0003Va-99 for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Nov 2018 17:09:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJn1m-0000Pp-5K for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 17:07:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJmsl-0004ng-HR for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 16:58:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59781) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJmsk-0004md-Gi for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 16:58:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJmsk-0006br-F3 for bug-gnu-emacs@gnu.org; Mon, 05 Nov 2018 16:58: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: Mon, 05 Nov 2018 21:58: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.154145506625370 (code B ref 32825); Mon, 05 Nov 2018 21:58:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 5 Nov 2018 21:57:46 +0000 Original-Received: from localhost ([127.0.0.1]:35803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJmsT-0006b8-OQ for submit@debbugs.gnu.org; Mon, 05 Nov 2018 16:57:45 -0500 Original-Received: from lavender.maple.relay.mailchannels.net ([23.83.214.99]:42547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJmsR-0006ar-GS for 32825@debbugs.gnu.org; Mon, 05 Nov 2018 16:57:44 -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 B1ECD123F87; Mon, 5 Nov 2018 21:57:41 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a31.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 32919123F23; Mon, 5 Nov 2018 21:57:41 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a31.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); Mon, 05 Nov 2018 21:57:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Arch-Well-Made: 0d43b76831440a95_1541455061348_378666078 X-MC-Loop-Signature: 1541455061348:2714687240 X-MC-Ingress-Time: 1541455061347 Original-Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id E4C58804D4; Mon, 5 Nov 2018 13:57:40 -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=uEED/3Qcn2mjqmaSLNBEFFWGFgs=; b= xKtORk2nd14r6K+z8G4MzXkrf94EjwvJnfIQJgkqIz6l/0Hqhx+1K9T4fPaFDELh fEtwBj1MbKSNhW3tG4zU4gzhmrF1rVOl08skAyOXVKlYVTSIzhwkkbsaGyyF3XoW 0QsIo9f2S9ozGfQ+y/9v3W6JGF0uxCvbtLm1NpXtGhE= 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-a31.g.dreamhost.com (Postfix) with ESMTPSA id 42EF38049A; Mon, 5 Nov 2018 13:57:37 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a31 In-Reply-To: <5BE00EB1.6090107@gmx.at> (martin rudalics's message of "Mon, 05 Nov 2018 10:34:41 +0100") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeehgdduheejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdejrddvgeegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddtjedrvdeggedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehruhgurghlihgtshesghhmgidrrghtnecuvehluhhsthgvrhfuihiivgeptd 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:152085 Archived-At: >>> (1) Decide whether a specific window can be (re-)used. Should we >>> refute it when the window cannot be enlarged to 'min-height' lines? >>> The decision would have to be made via 'window-resizable-p' and its >>> IGNORE argument set to the window itself so we can, for example, >>> (re-)use a preserved size window showing some other buffer. >>> >>> (2) Actually resize that window via a 'window-height' entry. This is >>> independent from (1). Processing a 'window-height' entry is just some >>> sort of bonus work 'display-buffer' does for the convenience of the >>> user. It in now way affects the decision which window is chosen. >>> >>> So please think of any bad consequences of what we decide in (1) like >>> not using _any_ window on the selected frame because none of them fits >>> the 'min-height' constraint. Consider a default two windows frame >>> where the size of the selected window is preserved. >> >> Maybe simply display the buffer in the below window regardless of its >> size? Because it makes no sense for display-buffer-below-selected to >> display the buffer in a window other than below. > > But then the same argument holds for popping up a new window. Even > if we can't make the new window as large as we want, popping it up > below the selected one is the only thing that makes sense if the > selected window is at the bottom of the frame. Unless we decide that > failing should be better than not making the window high enough. Maybe I misunderstand something, but I see that already everything is working fine. When I tried with display-buffer-below-selected to cause an error in a narrow buffer at the bottom of the frame, then the *Backtrace* buffer is displayed in a new window created by horizontal splitting of the largest window on the frame.