starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

More convenient shortcut key for opening new Tab(s). #7990

New Issue
Closed
opened 2026-01-31 01:17:51 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 01:17:51 +00:00
Owner
Copy Link

Originally created by @raxraj on GitHub (May 7, 2020).

Description of the new feature/enhancement

A more suitable way to open new tabs, with the latest release as of now, the CTRL+Tab to switch between tabs was brought back, but to open new tabs it is still set to ctrl+shift+1 and show on.
For default new Tab it is set to Ctrl+Shift+T which doesn't appear much convenient. I believe we need the Ctrl+T way to open a new tab, which brings consistency in the way new tabs open in every other software.

Proposed technical implementation details (optional)

Well it is simple I just believe that CTRL+TAB is there for changing tabs then I guess we pretty much need CTRL+T to open a new tab with default and CTRL+1, CTRL+2, etc for the others.
Though CTRL+1, 2, etc are optional CTRL+T is a requirement I believe.

More Details

I understand it pretty well, that we can change it using the JSON keybindings, but I am requesting it as a default behavior and not as a customization.

Originally created by @raxraj on GitHub (May 7, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement A more suitable way to open new tabs, with the latest release as of now, the CTRL+Tab to switch between tabs was brought back, but to open new tabs it is still set to ctrl+shift+1 and show on. For default new Tab it is set to Ctrl+Shift+T which doesn't appear much convenient. I believe we need the Ctrl+T way to open a new tab, which brings consistency in the way new tabs open in every other software. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. --> Well it is simple I just believe that CTRL+TAB is there for changing tabs then I guess we pretty much need CTRL+T to open a new tab with default and CTRL+1, CTRL+2, etc for the others. Though CTRL+1, 2, etc are optional CTRL+T is a requirement I believe. # More Details I understand it pretty well, that we can change it using the JSON keybindings, but I am requesting it as a default behavior and not as a customization.
claunia commented 2026-01-31 01:17:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 7, 2020):

Thanks for the suggestion! We've played with the defaults pretty extensively over the last year, and we've found that the Ctrl+Shift+key versions of the keyboard shortcuts are almost always better. The main reason is that a lot of commandline applications already have actions bound to Ctrl+key key chords. If the Terminal were to bind these keys by default, then most users would have to opt out of these keybindings. It's been less painful to instead have the few users who want to use Ctrl+key chords for the Terminal shortcuts to opt-in to them.

@zadjii-msft commented on GitHub (May 7, 2020): Thanks for the suggestion! We've played with the defaults pretty extensively over the last year, and we've found that the <kbd>Ctrl+Shift+key</kbd> versions of the keyboard shortcuts are almost _always_ better. The main reason is that a lot of commandline applications already have actions bound to <kbd>Ctrl+key</kbd> key chords. If the Terminal were to bind these keys by default, then most users would have to opt _out_ of these keybindings. It's been less painful to instead have the few users who want to use <kbd>Ctrl+key</kbd> chords for the Terminal shortcuts to opt-_in_ to them.
claunia commented 2026-01-31 01:17:52 +00:00
Author
Owner
Copy Link

@raxraj commented on GitHub (May 7, 2020):

@zadjii-msft Well I understand the fact that you're stating.
But I recently shifted from the Ubuntu to Windows, just because of the Terminal and the Linux Subsystem being available on Windows.
And Ubuntu Terminal, as well as other Linux env have a Ctrl+key for the new tab, and I still believe it won't be a major problem with Ctrl+T since it is the most prominent for new tabs among all the terminals and CLI dev know this fact.

But Yet, if the dev team thinks it's for the best, then I think we have to assume it.

@raxraj commented on GitHub (May 7, 2020): @zadjii-msft Well I understand the fact that you're stating. But I recently shifted from the Ubuntu to Windows, just because of the Terminal and the Linux Subsystem being available on Windows. And Ubuntu Terminal, as well as other Linux env have a Ctrl+key for the new tab, and I still believe it won't be a major problem with Ctrl+T since it is the most prominent for new tabs among all the terminals and CLI dev know this fact. But Yet, if the dev team thinks it's for the best, then I think we have to assume it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Issue-Question Needs-Triage Product-Terminal Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7990
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?