unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Brian Mingus <reflection@gmail.com>
To: 52363@debbugs.gnu.org
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	[thread overview]
Message-ID: <CADTVsF9T0qYJbZLVO3rpGvmtcNY8=g+SG5_QCu8fJJ6fmb=TWA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2395 bytes --]

                 reply	other threads:[~2021-12-07 18:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADTVsF9T0qYJbZLVO3rpGvmtcNY8=g+SG5_QCu8fJJ6fmb=TWA@mail.gmail.com' \
    --to=reflection@gmail.com \
    --cc=52363@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).