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

[Juri Linkov]

> 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.

And I agree that we should do something to fix this behavior.
But what to do exactly is not yet clear.

While looking at the tabs as frames grouped inside one frame, then
by analogy we could do the same how read-minibuffer-restore-windows
behaves in regard to frames.  After replacing 'C-x t' with 'C-x 5'
in your test case, I see that read-minibuffer-restore-windows=t
works inconsistently.  You can also try to change buffers
in both frames while the minibuffer is active.  Then exiting
the minibuffer does unexpected things.

So maybe tabs would need own solution, e.g. with a new variable
read-minibuffer-restore-tabs based on read-minibuffer-restore-windows,
or a new variable minibuffer-follows-selected-tab based on
minibuffer-follows-selected-frame.