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

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

[Spencer Baugh]

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.


In GNU Emacs 29.0.90 (build 9, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-06-13 built on
 igm-qws-u22796a
Repository revision: 2ff60641725661c306ed172ca09a8452d9be0db1
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --with-gif=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr cl-print byte-opt gv bytecomp byte-compile debug
backtrace find-func thingatpt help-fns radix-tree emacsbug message
mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils subr-x cl-extra help-mode icons
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 76697 13286)
 (symbols 48 10635 0)
 (strings 32 27067 2042)
 (string-bytes 1 806210)
 (vectors 16 12147)
 (vector-slots 8 176898 14217)
 (floats 8 40 52)
 (intervals 56 423 53)
 (buffers 976 14)
 (heap 1024 13951 1022))

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

[Juri Linkov]

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

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

[sbaugh]

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.

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

[Juri Linkov]

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

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

[Spencer Baugh]

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.

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.

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

[Juri Linkov]

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

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

I was unaware about this problem because I have customized
read-minibuffer-restore-windows to nil.  Now that you found the problem,
I looked at it from the point of view of users who don't mind the
default value t of read-minibuffer-restore-windows, and agree now
that for read-minibuffer-restore-windows to continue doing
what it's intended to do, the only way is to switch to the
original tab back.  Here is a preliminary patch that might
need more testing:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar-minibuffer-restore-windows.patch --]
[-- Type: text/x-diff, Size: 1289 bytes --]

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 87ca80ce00a..f0668374773 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1253,6 +1260,14 @@ tab-bar--tabs-recent
                              tabs))))
 
 \f
+(defvar tab-bar-minibuffer-restore-tab nil)
+
+(defun tab-bar-minibuffer-restore-windows ()
+  (when (and read-minibuffer-restore-windows
+             tab-bar-minibuffer-restore-tab)
+    (tab-bar-select-tab tab-bar-minibuffer-restore-tab)
+    (setq tab-bar-minibuffer-restore-tab nil)))
+
 (defun tab-bar-select-tab (&optional tab-number)
   "Switch to the tab by its absolute position TAB-NUMBER in the tab bar.
 When this command is bound to a numeric key (with a key prefix or modifier key
@@ -1278,6 +1293,11 @@ tab-bar-select-tab
          (to-index (1- (max 1 (min to-number (length tabs)))))
          (minibuffer-was-active (minibuffer-window-active-p (selected-window))))
 
+    (when (and read-minibuffer-restore-windows minibuffer-was-active
+               (not tab-bar-minibuffer-restore-tab))
+      (setq tab-bar-minibuffer-restore-tab (1+ from-index))
+      (add-hook 'minibuffer-exit-hook 'tab-bar-minibuffer-restore-windows))
+
     (unless (eq from-index to-index)
       (let* ((from-tab (tab-bar--tab))
              (to-tab (nth to-index tabs))

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

[Juri Linkov]

close 64373 30.0.50
thanks

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

Thanks for bringing up this problem.  Now it's fixed in master.