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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: sbaugh <at> catern.com
Cc: 64373 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: bug#64373: 29.0.90; C-x t o while in minibuffer copies the current tab to the next tab
Date: Fri, 30 Jun 2023 21:52:56 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.