GNU bug report logs - #58728
29.0.50; Minibuffer does not follow tabs

Previous Next

Full log

Message #11 received at 58728 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 58728 <at> debbugs.gnu.org
Subject: Re: bug#58728: 29.0.50; Minibuffer does not follow tabs
Date: Tue, 25 Oct 2022 22:14:03 +0300

> I'm not sure if this qualifies as a bug or as a feature request but:
> minibuffers should follow tabs like they follow frames.  To reproduce,
>
>     1. emacs -Q
>     2. C-x t 2
>     3. M-x
>     4. C-x t o
>
> Observe how the minibuffer is not active in this tab so you can't
> complete your query.  You need to switch back to the tab where the M-x
> command was run to get back the minibuffer.
> [ The current behaviour makes for really confusing behaviour when
>   recursive minibuffers are involved.  ]

Currently the only code that handles the active minibuffer
is in tab-bar-new-tab-to:

      ;; Handle the case when it's called in the active minibuffer.
      (when (minibuffer-selected-window)
        (select-window (minibuffer-selected-window)))

that ensures that the minibuffer is not selected before creating a new tab.

So should the new feature handle all cases: when a new tab is created and
when switching existing tabs?  In both cases the minibuffer should follow
the selected tab?

Currently selecting a tab just restores its window-configuration.
Should it activate the same minibuffer that was active in a previous tab?
What if two tabs have separate minibuffers?  Which minibuffer wins?
In a test case:

    1. emacs -Q
    2. C-x t 2
    3. M-x
    4. C-x t o
    5. M-:
    6. C-x t o

what minibuffer should be displayed?  Probably the last.

Previous Next

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