From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Brian Mingus Newsgroups: gmane.emacs.bugs Subject: bug#52363: Disallow modes from re-arranging windows if the user specified a window layout Date: Tue, 7 Dec 2021 11:56:46 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007c9f1a05d292f18c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14485"; mail-complaints-to="usenet@ciao.gmane.io" To: 52363@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 07 23:18:18 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muimw-0003a6-8G for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Dec 2021 23:18:18 +0100 Original-Received: from localhost ([::1]:34660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muimu-0007Dv-Eg for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Dec 2021 17:18:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muimp-0007Dn-F4 for bug-gnu-emacs@gnu.org; Tue, 07 Dec 2021 17:18:11 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1muimg-0004t9-Pr for bug-gnu-emacs@gnu.org; Tue, 07 Dec 2021 17:18:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1muimg-0001Au-Ll for bug-gnu-emacs@gnu.org; Tue, 07 Dec 2021 17:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Brian Mingus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Dec 2021 22:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 52363 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.16389154564478 (code B ref -1); Tue, 07 Dec 2021 22:18:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 7 Dec 2021 22:17:36 +0000 Original-Received: from localhost ([127.0.0.1]:38915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muimF-0001A9-0k for submit@debbugs.gnu.org; Tue, 07 Dec 2021 17:17:36 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:51616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mufeY-0008Dn-QX for submit@debbugs.gnu.org; Tue, 07 Dec 2021 13:57:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mufeY-00056i-GD for bug-gnu-emacs@gnu.org; Tue, 07 Dec 2021 13:57:26 -0500 Original-Received: from [2a00:1450:4864:20::133] (port=40498 helo=mail-lf1-x133.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mufeW-0005iT-I7 for bug-gnu-emacs@gnu.org; Tue, 07 Dec 2021 13:57:26 -0500 Original-Received: by mail-lf1-x133.google.com with SMTP id l22so497930lfg.7 for ; Tue, 07 Dec 2021 10:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=5ZHgFGFny8BM7myh+nzgx7tvbIkDCY4RwGHhFuhp+1o=; b=enB0CSRfzcbFSwMPqkv9Mfap9va5ui9p+5lM3U08uAhmrRp4dMXspD3UVYF1tWQE/3 nPqvEtNoP+IvK4CSNjMix6uM3gitPnyZvTzB6wJbuR2WDdx93mCyzuaxUfCXxAFybC03 6xvGkp+S1/uKGTTIsr85YFP9KuoQxxyZriwjrZRLDVZFq+kA41TeTeGHnnID7QjTZRLG tGzkXWiu3D0RF73/NI1CY4CO4JmUCPlW3FzdV5c06NL9GUsVSQ70yQvFxPn/3gU8Aq9S g69vwynWry53cURoI0ZNL7Hcip6dAADMNOAyDHdZyJS1L0E5g1pMH0gNQVhi1qxfgpyg vVqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5ZHgFGFny8BM7myh+nzgx7tvbIkDCY4RwGHhFuhp+1o=; b=rIvFGaDyO8r1OmzEs918XPx+6ndK2BzLHAOgV+S71XM0O+Avl6/StN3Mj+rV0iBJyM yCVsM1cVLOLSOe9nxXHC2qOxURxPnQTcJdIZDWSihjoE1tP1xrb0SwG7LXeepWKH3rxa aHIPj+nYir8Am4IEb9P3r7ebkfOEXxcDswforsWAc92sElW/0rJ/UIBJxIR4BqXQXkQ1 KqZgbdMVk0WG6f9c08ArtrnfKBjiiLjze0DXbwjuijWCDy9xGCXbJG+cWQuTe7w2xUVD vOvhtv7NAaklZRM9pELpeklRaj++TcWps/vcPrybBpI9P52beIq+R8kvtGiYgWpJRzeA EOIg== X-Gm-Message-State: AOAM531hflhJEKYE+lKY9Bb0jSe+vWDCkuCJLb1IBLazw8WB7wJMAqyx i1a6ZPprWOdhhoU5eFbmrc/dQ9f/bSyuj2LSz7VSaczgheQLFw== X-Google-Smtp-Source: ABdhPJwygn7i4lHwcbt1IV57OQOfJCvJds5yMBgDN6AnNhbk64V8HB9YMgwyVPj1qnLCplKiOKPB1Fd5gt8+kGw52ns= X-Received: by 2002:ac2:5d28:: with SMTP id i8mr42365598lfb.394.1638903442086; Tue, 07 Dec 2021 10:57:22 -0800 (PST) X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::133 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::133; envelope-from=reflection@gmail.com; helo=mail-lf1-x133.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 07 Dec 2021 17:17:33 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221885 Archived-At: --0000000000007c9f1a05d292f18c Content-Type: text/plain; charset="UTF-8" A variety of modes including python-mode.el will re-arrange the user's window layout when certain commands are issued. For example, in python-mode.el, if the user has used Ctrl-x 3 to create a horizontal split with the code on the left, when the user issues Ctrl-c ! to create a REPL, python-mode.el will re-arrange the windows to have a vertical split. Propose to nerf this behavior in the case that the user has manually re-arranged their windows, unless the mode sets a special flag indicating they are a special mode that only helps the user manage windows. This shouldn't break many modes, as the mode would need to work contingent on the user's window layout. Nearly all modes would continue to work based on the existence of their buffers. Thus, if the user has entered Ctrl-x 1|2|3 at any time, modes would not be allowed to automatically re-arrange the windows. This behavior works as expected for most use cases. For example, a user using Ctrl-x 2|3 to create a window before running M-x shell with the focus in that window, will only observe expected behavior. There are special modes for this such as shackle, and several others. However, providing default behavior that makes sense to the user could clear up a lot of confusion. In the case that a mode needs two windows, it is quite difficult for the user to manage this. For example, you must use use set-window-dedicated-p on all but two windows, so the new buffers will pop (basically randomly) in either of the two available slots (if two are available). In the case that a mode needs two slots and intends to create them if not available, the special flag indicating that this is a mode that helps the user manage more complex window layouts could be set for that mode automatically on recognition of that behavior, as the mode can be considered as providing an IDE for the user. As an initial first step for this feature, if the user has either a horizontal split or a vertical split, no mode without the special flag should be allowed to switch it the other way around. Sincerely, Brian --0000000000007c9f1a05d292f18c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A variety of modes including python-mode.el will re-arrang= e the user's window layout when certain commands are issued.=C2=A0
=
For example, in python-mode.el, if the user has used Ctrl-x = 3 to create a horizontal split with the code on the left, when the user iss= ues Ctrl-c ! to create a REPL, python-mode.el will re-arrange the windows t= o have a vertical split.=C2=A0

Propose to nerf thi= s behavior in the case that the user has manually re-arranged their windows= , unless the mode sets a special flag indicating they are a special mode th= at only helps the user manage windows. This shouldn't break many modes,= =C2=A0 as the mode would need to work contingent on the user's window l= ayout. Nearly all modes would continue to work based on the existence of th= eir buffers.

Thus, if the user has entered Ctrl-x = 1|2|3 at any time, modes would not be allowed to automatically re-arrange t= he windows.

This behavior works as expected for mo= st use cases. For example, a user using Ctrl-x 2|3 to create a window befor= e running M-x shell with the focus in that window, will only observe expect= ed behavior.

There are special modes for this such= as shackle, and several others. However, providing default behavior that m= akes sense to the user could clear up a lot of confusion.

In the case that a mode needs two windows, it is quite difficult fo= r the user to manage this. For example, you must use use set-window-dedicat= ed-p on all but two windows, so the new buffers will pop (basically randoml= y) in either of the two available slots (if two are available).=C2=A0
=

In the case that a mode needs two slots and intends to = create them if not available, the special flag indicating that this is a mo= de that helps the user manage more complex window layouts could be set for = that mode automatically on recognition of that behavior, as the mode can be= considered as providing an IDE for the user.

As a= n initial first step for this feature, if the user has either a horizontal = split or a vertical split, no mode without the special flag should be allow= ed to switch it the other way around.

Sincerely,

Brian



<= /div>
--0000000000007c9f1a05d292f18c--