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: Wed, 21 Nov 2018 02:16:46 +0200 Organization: LINKOV.NET Message-ID: <87ftvvw93d.fsf@mail.linkov.net> References: <874leeaiah.fsf@mail.linkov.net> <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> <5BF3D494.90607@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1542761351 14543 195.159.176.226 (21 Nov 2018 00:49:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 00:49:11 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 32825@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 21 01:49:06 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 1gPGhU-0003dN-PH for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Nov 2018 01:49:05 +0100 Original-Received: from localhost ([::1]:36665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPGjb-0001YI-Ab for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2018 19:51:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPGjT-0001Y3-BO for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 19:51:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPGjO-0001LJ-9y for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 19:51:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33342) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gPGjO-0001L8-6l for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 19:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gPGjO-00065M-4h for bug-gnu-emacs@gnu.org; Tue, 20 Nov 2018 19:51: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: Wed, 21 Nov 2018 00:51: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.154276142823343 (code B ref 32825); Wed, 21 Nov 2018 00:51:02 +0000 Original-Received: (at 32825) by debbugs.gnu.org; 21 Nov 2018 00:50:28 +0000 Original-Received: from localhost ([127.0.0.1]:37599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPGiq-00064R-Ex for submit@debbugs.gnu.org; Tue, 20 Nov 2018 19:50:28 -0500 Original-Received: from eastern.maple.relay.mailchannels.net ([23.83.214.55]:1821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gPGio-00064J-Ef for 32825@debbugs.gnu.org; Tue, 20 Nov 2018 19:50:26 -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 20022282DEA; Wed, 21 Nov 2018 00:50:25 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a37.g.dreamhost.com (unknown [100.96.20.98]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D4995283461; Wed, 21 Nov 2018 00:50:24 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a37.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); Wed, 21 Nov 2018 00:50:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Exultant-Desert: 5d2848c0322c6d89_1542761424966_682926318 X-MC-Loop-Signature: 1542761424965:569611750 X-MC-Ingress-Time: 1542761424965 Original-Received: from pdx1-sub0-mail-a37.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a37.g.dreamhost.com (Postfix) with ESMTP id 97D4A808D2; Tue, 20 Nov 2018 16:50:24 -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=vZUryI0Y8gz7dPHWzi1xkM/kpaU=; b= rzNg3sgsaOvr0LmEv4N7JW3dyXnj1BiH8ZrhKnr3f11dhcrgn3No3O2LDWHpITIA GLj7HWGoQZzoXQDutd5tDW7U8FrEAFPyo7dvq9NQ9YASkaCor1Vpt29IOUjieVXR 27POPuwU+I696080SpIUeEfZ5K390DsJBeSR8TIkk+c= Original-Received: from mail.jurta.org (m91-129-105-252.cust.tele2.ee [91.129.105.252]) (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-a37.g.dreamhost.com (Postfix) with ESMTPSA id B65AD808D3; Tue, 20 Nov 2018 16:50:22 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a37 In-Reply-To: <5BF3D494.90607@gmx.at> (martin rudalics's message of "Tue, 20 Nov 2018 10:32:04 +0100") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedruddtiedgvdekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdehrddvhedvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddthedrvdehvddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehruhgurghlihgtshesghhmgidrrghtnecuvehluhhsthgvrhfuihiivgepud 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:152605 Archived-At: > 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. I imagine a list of prev/next-buffers as the tab-bar: [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] prev-buffers current-buffer next-buffers Using switch-to-buffer adds a new buffer after the current "tab", e.g. [buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E] prev-buffers current-buffer next-buffers But displaying a temporary buffer could add a "tab" to the end of the tab-bar, this means at the end of the list of next-buffers: [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer] prev-buffers current-buffer After exiting from this temporary buffer, it could be kept in the list of next-buffers: [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer] prev-buffers current-buffer next-buffers Then returning to prev-buffers (e.g. with kill-buffer) will not visit this temporary buffer. But display-buffer-reuse-window could look for a previously displayed buffer in the list of next buffers. > 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. We could have a general shorter name like 'dir', and more specific longer names like 'select-dir' and 'split-dir'. If no long entries are found, then fall back to a shorter name.