New config setting for new tab active state

[edrozenberg]

Context:
Currently when creating a new Ghostty tab, it is made active. This is the MacOS default and matches default behavior in apps such as Terminal.app & Alacritty. This makes sense in most cases - the user creates a new tab/window, in order to immediately do something in the new tab/window.

Idea:
A new config item to control this, something like the following for ex:
window-new-tab-active = < true | false > (default = true)

This would allow the user to spec whether a newly created tab is set to active. If false, the new tab would not be set active, active state would remain with the tab/window the user was already on when the new tab was created.

Motivation:
For certain user workflows, it may be beneficial to be able to create new tabs without being automatically switched away from the current tab to the blank new tabs.

One app that provides this feature is Safari, there are probably others but haven't investigated. I'd guess iTerm may, as it provides every other feature proposed, invented, considered, or contemplated.

This same consideration may also apply to the creation of new windows, but it's easy to argue that when creating a new window, it should always be made active, which is the MacOS default and also the Ghostty default. The philosophy around this may be that if a user is creating a new window, the new window will typically cover at least part of the previous window and anyway a new window indicates a user desire to switch their attention to working with this new window.

The Safari setting ("When a new tab or window opens, make it active") in theory controls the behavior for both new tab & new window scenarios, but afaict it may be bugged wrt new window since for me, even with that setting OFF, a new Safari window is always made active.

If Ghostty would want to control both at once or separately, maybe something like the following (don't know if the naming here is great):
new-surface-active = < tab | window | both/all | none/false >

(new-surface-active vs. surface-new-active vs. surface-new-surface-active ¯\_(ツ)_/¯ )

There may be similar considerations on Linux, I'm not very familiar with how various Linux wm's think about this topic.

[pluiedev]

Obligatory question: does any other terminal emulator (or program in general) do this? I can see the merit of this if you want to spam-open a ton of tabs but it's better to have some precedent for design.

[pluiedev]

Same - from the GUI side I think it would make sense if say, shift-clicking the new tab button creates an unfocused tab, for example

[edrozenberg]

Thanks! I wasn't able to find this functionality in alacritty.org/config-alacritty.html or in iTerm2-3_5_20250209-nightly. After searching iTerm2 adv settings w/ 'focus', 'activ', the closest thing I could find is related to mouse (ffm) and splits, but this is not relevant to the current discussion imo:

It's a feature that's more theoretically useful than one needed by many, and something I've only seen in Safari afaik. If anything, it's something iTerm would consider implementing, and not Ghostty :). Not to bash iTerm, I mainly dislike its unattractive lower case iName from 90's and never wanted to use it mainly for this reason, since after all it's nice that someone slings some kitchen sinks around for those who like 'em slung.

I can close this, unless there are some additional voters who make a case for it.

[edrozenberg]

Following up on the Safari behavior, opening blank new tabs in Safari always focuses/activates them.

The scenario where new Safari tabs are NOT active is when opening urls in new tabs from url's on the current page - this is useful for browsing scenarios such as opening many tabs from an index, reference or shopping page to browse one after the other such as for research purposes. Frequently used with Cmd+Click to quickly open many tabs from the current page without being switched away to a different tab on each click.

But don't see this being useful or analogous in a terminal unless there are scenarios where the contents of the current terminal tab/window would be used in some way to determine the varying contents of new terminal tabs/windows being created. Not aware of any such scenario atm.

[pluiedev]

Yeah if it's only used in that instance then it makes little sense for a terminal emulator IMO.

[edrozenberg]

Closed for lack of a good terminal scenario. Thanks for the feedback!