wt new-tab --no-focus, to keep the focus in the current tab rather than the new tab #21888

Open
opened 2026-01-31 07:57:30 +00:00 by claunia · 5 comments
Owner

Originally created by @KalleOlaviNiemitalo on GitHub (Jun 21, 2024).

Description of the new feature/enhancement

Add to wt new-tab an option that makes it keep the focus in the current tab, instead of switching to the new tab.
I think --no-focus would be a good name for the new option, and consistent with the focus-tab command.

I'd use this in a Bash alias that starts a console application that takes some time to initialize. So I'd be able to continue working in the shell while the application is initializing, and switch to the application's tab a bit later.

Proposed technical implementation details (optional)

Originally created by @KalleOlaviNiemitalo on GitHub (Jun 21, 2024). # Description of the new feature/enhancement Add to `wt new-tab` an option that makes it keep the focus in the current tab, instead of switching to the new tab. I think `--no-focus` would be a good name for the new option, and consistent with the `focus-tab` command. I'd use this in a Bash alias that starts a console application that takes some time to initialize. So I'd be able to continue working in the shell while the application is initializing, and switch to the application's tab a bit later. # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureProduct-TerminalArea-Commandline labels 2026-01-31 07:57:30 +00:00
Author
Owner

@PankajBhojwani commented on GitHub (Jun 26, 2024):

This sounds interesting! Thank you for submitting this.

We have some concerns about how this would interact with some other commandline arguments (like split pane), so we are going to put this on the backlog and mark it as requiring a spec.

@PankajBhojwani commented on GitHub (Jun 26, 2024): This sounds interesting! Thank you for submitting this. We have some concerns about how this would interact with some other commandline arguments (like split pane), so we are going to put this on the backlog and mark it as requiring a spec.
Author
Owner

@KalleOlaviNiemitalo commented on GitHub (Jun 27, 2024):

I don't understand the concern about split pane. new-tab and split-pane are separate commands and don't have to support all the same options.

@KalleOlaviNiemitalo commented on GitHub (Jun 27, 2024): I don't understand the concern about split pane. `new-tab` and `split-pane` are separate commands and don't have to support all the same options.
Author
Owner

@DHowett commented on GitHub (Jun 27, 2024):

They may not have to, but they should. They're both different localities for "make a new teminal control somewhere". split-pane focuses the new terminal, and if we're going to implement this for one type of "make-new-terminal" we should do it for all of them.

But then... should it be part of the action language as well? e.g. should you be able to bind Ctrl+Shift+B to open a new unfocused tab in the background?

What about new-window? Or the actions for moving a tab to a different window? Those all focus the new tab too... 🤔

@DHowett commented on GitHub (Jun 27, 2024): They may not have to, but they _should_. They're both different localities for "make a new teminal control somewhere". `split-pane` focuses the new terminal, and if we're going to implement this for one type of "make-new-terminal" we should do it for all of them. But then... should it be part of the action language as well? e.g. should you be able to bind <kbd>Ctrl+Shift+B</kbd> to open a new unfocused tab in the background? What about `new-window`? Or the actions for moving a tab to a different window? Those all focus the new tab too... 🤔
Author
Owner

@mkatch commented on GitHub (Jan 2, 2025):

It doesn't sound like something hard to specify: whenever any action would actively move focus, it shouldn't.

Indeed, when interacting with other windows, it may become tricky, as the OS might automatically want to focus new windows (I don't know if that happens, but I can totally imagine it), but is it really a good reason to block all the low hanging fruits, like opening a new tab in the current window?

@mkatch commented on GitHub (Jan 2, 2025): It doesn't sound like something hard to specify: whenever any action would *actively* move focus, it shouldn't. Indeed, when interacting with other windows, it may become tricky, as the OS might automatically want to focus new windows (I don't know if that happens, but I can totally imagine it), but is it really a good reason to block all the low hanging fruits, like opening a new tab in the current window?
Author
Owner

@BessonovVyacheslav1 commented on GitHub (Nov 5, 2025):

I would also like a function like the middle mouse button, something like "open in a new tab but don't switch to it" but in the terminal

@BessonovVyacheslav1 commented on GitHub (Nov 5, 2025): I would also like a function like the middle mouse button, something like "open in a new tab but don't switch to it" but in the terminal
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#21888