bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows

[Juri Linkov <juri@linkov.net>]

>> Would it be possible to update 'minibuf_selected_window'
>> with a new window after deleting the original window?
>
> Not really.  We'd change existing behavior that might rely on the fact
> that 'minibuffer-selected-window' returns nil once it got deleted.
>
> Besides, it might not make you happy anyway.  With the default of
> 'minibuffer-follows-selected-frame', a user may correspond with a
> minibuffer window that resides on another frame than that returned by
> 'minibuffer-selected-window' and neither minibuf_selected_window nor
> Vminibuf_scroll_window may make sense any more in such context.
>
> Why don't you use 'get-mru-window' on the frame that owns the
> 'minibuffer-window' instead of 'minibuffer-selected-window'?

Thanks for the idea, this works perfectly:

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 42fc5a23990..0ae7fb44b27 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1339,8 +1340,7 @@ tab-bar-select-tab
 
          (ws
           ;; `window-state-put' fails when called in the minibuffer
-          (when (minibuffer-selected-window)
-            (select-window (minibuffer-selected-window)))
+          (when (minibufferp) (select-window (get-mru-window)))
           (window-state-put ws nil 'safe)))
 
         ;; Select the minibuffer when it was active before switching tabs
@@ -1575,8 +1575,7 @@ tab-bar-new-tab-to
 
     (when tab-bar-new-tab-choice
       ;; Handle the case when it's called in the active minibuffer.
-      (when (minibuffer-selected-window)
-        (select-window (minibuffer-selected-window)))
+      (when (minibufferp) (select-window (get-mru-window)))
       (let ((ignore-window-parameters t)
             (window--sides-inhibit-check t))
         (if (eq tab-bar-new-tab-choice 'clone)