bug#81406: 31.0.90; rotate-windows loses window balance when window-combination-resize is t

On Sun, Aug 9, 2026 at 5:29 AM Sean Whitton <[email protected]>
wrote:

> Stéphane Marks [07/Aug  4:50pm +02] wrote:
> > On Fri, Aug 7, 2026 at 10:47 AM Pranshu <[email protected]>
> wrote:
> >
> >> > I disagree, dedicated windows are windows that are dedicated to one
> >> > buffer, but that dosn't mean you can do stuff like split them or even
> >> > change their size.  rotate-windows is an exception, it seems like it's
> >> > moving the buffers around, but actually it's destroying and recreating
> >> > the window tree from scratch, so it gives the wrong impressoin.  The
> >> > other window-x don't have this issue, they're pretty clear about that
> >> > they do. Since dedicated windows are splittable, there's no reason why
> >> > they shouldn't be transposable etc.
> >>
> >> For a better analogy: Imagine a window is a person, and a buffer is
> >> the person's soul (etc their personality and memories).  A dedicated
> >> window is a person whose body is exclusive to their soul.  On the
> >> outside, rotate-windows looks like it swaps people's souls and bodys
> >> but the people stand exactly where they were, just their souls
> >> changed.  But in reality, rotate-windows changes the person's body and
> >> soul and moves them around to make it look like souls were swapped.
> >> The other window commmands for example flip windows, simply relocates
> >> people in predicatable way to have the people standing northmost go to
> >> the southmost point.
> >>
> >
> > I've always taken a window dedicated to its buffer to be precisely that
> and
> > nothing more; i.e., no expectations of the window being fixed in space.
> I
> > have only two dedicated windows I use daily and in a tab-bar tab that is
> > "locked" from being closed (that contribution coming in Emacs 32 along
> with
> > several other tab-bar improvements).
>
> Your positions here are perfectly reasonable, but so is the view that
> dedicated windows don't move.  That's why I think we should default to
> the latter (the commands refusing to operate) but make it easy for users
> to opt-in to the behaviour you describe.
>

My reading of the elisp documentation nodes on dedicated windows stressing
buffer-window dedication and not stressing windows being fixed in space
bear out the position.  The documentation does talk about handling a
dedicated window when it is the sole window in a frame and
buffer-replacement behavior but is otherwise silent on window movement.  I
think I understand that you're interpretation being more "pedantic" than
Pranshu's (and my) position that a user sees a logical window object
dedicated to a buffer vs. a single window object itself never being
replaced in a window tree.  Restoring a window configuration from a
register or using tab-bar, as examples, do not come with a strong guarantee
that a window object at a particular memory address will remain constant?