bug#64373: 29.0.90; C-x t o while in minibuffer copies the current tab to the next tab

[Spencer Baugh <sbaugh@janestreet.com>]

Juri Linkov <juri@linkov.net> writes:
>>>> 1. emacs -Q
>>>> 2. C-x t 2 to create a new tab
>>>> 3. C-x b *Messages* RET
>>>>    Now the first tab should have only *scratch* open,
>>>>    and the second tab should have only *Messages* open,
>>>>    and we're in the second tab.
>>>> 4. M-: (read-from-minibuffer "") RET
>>>> 5. While in minibuffer, C-x t o to switch to the first tab
>>>> 6. RET to exit minibuffer
>>>> 7. The first tab now has *Messages* open.
>>>>
>>>> This also applies to more complicated window configurations: the whole
>>>> window configuration will be copied from the tab that the minibuffer was
>>>> first open in, to the tab that was entered with C-x t o.
>>>>
>>>> This also happens if the minibuffer is exited with C-g.
>>>
>>> Not a bug, this is the documented behavior.
>>> You can customize read-minibuffer-restore-windows to nil
>>> if you don't like this.
>>
>> We should also restore the current tab, then.  Because right now we're
>> restoring the window configuration, but not the current tab.
>>
>> If we did that, then this would behave as expected: We'd restore the
>> current tab, then restore the window configuration in that tab.
>
> We should not switch tabs without user's consent.
> Even restoring the window configuration is the wrong thing to do.
> I don't know why read-minibuffer-restore-windows should be enabled
> by default.  Maybe it should be disabled at least when the active
> minibuffer switches to another tab.

I agree we should not switch tabs without user's consent.  However I
would argue that tabs are basically part of window configuration, since
they're a way of managing named window configurations, and if the user
has set read-minibuffer-restore-windows to t then we should should
restore the current tab as part of window configuration.

I also agree that read-minibuffer-restore-windows should probably
default to nil.  But that's a separate discussion, changing a more
significant default.

Again: The current behavior of read-minibuffer-restore-windows is to
restore window configurations, but not restore the tab.  I say this is a
bug, even if it's documented as doing that, which it is not.  It clearly
behaves badly, wiping out user data without user action: It wipes out
the window configuration in the tab that the user switched to.  That's
definitely bad.