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

Default bindings are unusual for people who expect them to be usual #1897

New Issue
Closed
opened 2026-01-30 22:41:29 +00:00 by claunia · 13 comments
claunia commented 2026-01-30 22:41:29 +00:00
Owner
Copy Link

Originally created by @inputfalken on GitHub (Jun 22, 2019).

Originally assigned to: @zadjii-msft on GitHub.

Environment

Microsoft Windows [Version 10.0.18362.175]

Vim/Neovim

Steps to reproduce

Have a program running in the terminal that listens to bindings that conflict with Windows Terminal.

I noticed this in Vim when switching split editing windows of Vim. The binding is <Ctrl>+<w> and then any of <h> <j> <k> <l>.

The terminal starts crashing at this point.

Expected behavior

Not sure, for my particular issue I managed to fix this by changing the closeTab command from ctrl+w to something else.

Maybe this is Intended?

Actual behavior

The terminal crashes.

Originally created by @inputfalken on GitHub (Jun 22, 2019). Originally assigned to: @zadjii-msft on GitHub. <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Microsoft Windows [Version 10.0.18362.175] Vim/Neovim ``` # Steps to reproduce Have a program running in the terminal that listens to bindings that conflict with Windows Terminal. I noticed this in Vim when switching split editing windows of Vim. The binding is `<Ctrl>+<w>` and then any of `<h> <j> <k> <l>`. The terminal starts crashing at this point. # Expected behavior Not sure, for my particular issue I managed to fix this by changing the `closeTab` command from `ctrl+w` to something else. Maybe this is Intended? # Actual behavior The terminal crashes.
claunia commented 2026-01-30 22:41:30 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 22, 2019):

The crash is #1339 #1380 (1380 is the new reopened version of the bug). The key bindings are not yet tracked but I agree that ctrl+w is an annoying conflict.

@DHowett-MSFT commented on GitHub (Jun 22, 2019): The crash is #1339 #1380 (1380 is the new reopened version of the bug). The key bindings are not yet tracked but I agree that ctrl+w is an annoying conflict.
claunia commented 2026-01-30 22:41:30 +00:00
Author
Owner
Copy Link

@compnerd commented on GitHub (Jun 22, 2019):

@DHowett-MSFT ^W is the default keybinding for delete-word in readline, which means that Unix users stumble over it all the time (at least I do). I think that using the gnome-terminal defaults might be interesting (ctrl+shift+w for close, ctrl+shift+c for copy, ctrl+shift+v for paste, etc).

@compnerd commented on GitHub (Jun 22, 2019): @DHowett-MSFT ^W is the default keybinding for delete-word in readline, which means that Unix users stumble over it all the time (at least I do). I think that using the gnome-terminal defaults might be interesting (ctrl+shift+w for close, ctrl+shift+c for copy, ctrl+shift+v for paste, etc).
claunia commented 2026-01-30 22:41:30 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 22, 2019):

stumble over it all the time

That’s an understatement. I chose to rebind it and we should reconsider the defaults, or prompt the user which default bindings they prefer.

@DHowett-MSFT commented on GitHub (Jun 22, 2019): > stumble over it all the time That’s an understatement. I chose to rebind it and we should reconsider the defaults, or prompt the user which default bindings they prefer.
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@ibuioli commented on GitHub (Jun 23, 2019):

I am agree with this issue, the default shorcuts could be better. For example, Control + W is used in nano for searching terms. With the actual default settings the tab (or even the terminal) is closed suddenly. A new user could think that is a bug. The use of gnome-terminal default shorcut are a good choice (always allowing to be able to customize).

@ibuioli commented on GitHub (Jun 23, 2019): I am agree with this issue, the default shorcuts could be better. For example, Control + W is used in nano for searching terms. With the actual default settings the tab (or even the terminal) is closed suddenly. A new user could think that is a bug. The use of gnome-terminal default shorcut are a good choice (always allowing to be able to customize).
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 24, 2019):

Thoughts: maybe on first launch we ask if you're more used to X or Y style bindings? That could be a 2.0 feature.

@DHowett-MSFT commented on GitHub (Jun 24, 2019): Thoughts: maybe on first launch we ask if you're more used to X or Y style bindings? That could be a 2.0 feature.
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@darthwalsh commented on GitHub (Jun 29, 2019):

Getting a prompt on the first time you open an app is kind of annoying -- that's the beginning of a setup wizard.

An experience that might be neat is the first time you press ctrl+w it prompts you to ask if that should close the window?

But the simplest solution is to not set conflicting defaults, and let users add them. profiles.json supports comments, so the default profiles.json could contain:

// Uncomment to enable ctrl+w for closeTab
/* {
    "command" : "closeTab",
    "keys" : 
    [
        "ctrl+w"
    ]
}, */
@darthwalsh commented on GitHub (Jun 29, 2019): Getting a prompt on the first time you open an app is kind of annoying -- that's the beginning of a setup wizard. An experience that might be neat is the first time you press ctrl+w it prompts you to ask if that should close the window? But the simplest solution is to not set conflicting defaults, and let users add them. profiles.json supports comments, so the default profiles.json could contain: ```javascript // Uncomment to enable ctrl+w for closeTab /* { "command" : "closeTab", "keys" : [ "ctrl+w" ] }, */ ```
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@wmassingham commented on GitHub (Jul 1, 2019):

+1 to all of these. In a Linux-y shell, I reflexively hit Ctrl+W all the time. Apparently I hadn't disable that shortcut on this PC yet and it killed my terminal, ssh session, and remote text editor without so much as a prompt. Ideally Ctrl+W shouldn't be close tab, but it should at least warn about closing a tab with stuff running in it.

@wmassingham commented on GitHub (Jul 1, 2019): +1 to all of these. In a Linux-y shell, I reflexively hit Ctrl+W all the time. Apparently I hadn't disable that shortcut on this PC yet and it killed my terminal, ssh session, and remote text editor without so much as a prompt. Ideally Ctrl+W shouldn't be close tab, but it should at _least_ warn about closing a tab with stuff running in it.
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@notskm commented on GitHub (Jul 2, 2019):

An experience that might be neat is the first time you press ctrl+w it prompts you to ask if that should close the window?

I'm not at all a fan of the prompt idea regardless of when the prompt pops up. The terminal should just use sane defaults. If I don't like the defaults, I can change them manually. That's why there's a config file.

@notskm commented on GitHub (Jul 2, 2019): > An experience that might be neat is the first time you press ctrl+w it prompts you to ask if that should close the window? I'm not at all a fan of the prompt idea regardless of when the prompt pops up. The terminal should just use sane defaults. If I don't like the defaults, I can change them manually. That's why there's a config file.
claunia commented 2026-01-30 22:41:31 +00:00
Author
Owner
Copy Link

@Kyrluckechuck commented on GitHub (Jul 2, 2019):

As someone who just found out about this after accidentally closing my terminal 4 times in a row, I can testify that this is a very weird key combination to be having 'standard', especially for any who are using WSL and various linux tools that make sure of the normal key combination ctrl+w. Not trying to make this a +1, though it is a +1!

I understand they're trying to make this friendly for any who are coming from a web browser, but you need to make these key combinations work in mind with regular power users who will use nearly all of the standard regular key combinations, and if you're going to do destructive actions such as closing the tab, it definitely should require a third key in the combination.

Just my two cents, as I'm able to edit the bindings directly in the text settings file, but this would likely be off-putting for nearly anyone else coming to this terminal manager for the first time.

@Kyrluckechuck commented on GitHub (Jul 2, 2019): As someone who just found out about this after accidentally closing my terminal 4 times in a row, I can testify that this is a very weird key combination to be having 'standard', especially for any who are using WSL and various linux tools that make sure of the normal key combination `ctrl+w`. Not trying to make this a +1, though it is a +1! I understand they're trying to make this friendly for any who are coming from a web browser, but you need to make these key combinations work in mind with regular power users who will use nearly all of the standard `regular` key combinations, and if you're going to do destructive actions such as closing the tab, it definitely should require a third key in the combination. Just my two cents, as I'm able to edit the bindings directly in the text settings file, but this would likely be off-putting for nearly anyone else coming to this terminal manager for the first time.
claunia commented 2026-01-30 22:41:32 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 19, 2019):

Hey all, we're looking at changing some of the defaults here to require shift in addition to control to line up with other terminal emulators. PR #2014 makes that change. Is that something you're all comfortable with?

@DHowett-MSFT commented on GitHub (Jul 19, 2019): Hey all, we're looking at changing some of the defaults here to require shift in addition to control to line up with other terminal emulators. PR #2014 makes that change. Is that something you're all comfortable with?
claunia commented 2026-01-30 22:41:32 +00:00
Author
Owner
Copy Link

@gitfool commented on GitHub (Jul 19, 2019):

LGTM! I'm already overriding the defaults. Please also change CloseTab to require shift.

08565bd5a3/src/cascadia/TerminalApp/CascadiaSettings.cpp (L288-L290)

@gitfool commented on GitHub (Jul 19, 2019): LGTM! I'm already overriding the defaults. Please also change CloseTab to require shift. https://github.com/microsoft/terminal/blob/08565bd5a3bea6331b4abbd31f1224431102a2fd/src/cascadia/TerminalApp/CascadiaSettings.cpp#L288-L290
claunia commented 2026-01-30 22:41:32 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 19, 2019):

please also change

From the pull request,

"#2012 Changes "Close Window" by removing it by default, and adding ClosePane on Ctrl+Shift+W"

😄

@DHowett-MSFT commented on GitHub (Jul 19, 2019): > please also change From the pull request, > "#2012 Changes "Close Window" by removing it by default, and adding ClosePane on Ctrl+Shift+W" :smile:
claunia commented 2026-01-30 22:41:32 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 3, 2019):

:tada:This issue was addressed in #2014, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.🎉

Handy links:

@ghost commented on GitHub (Aug 3, 2019): :tada:This issue was addressed in #2014, which has now been successfully released as `Windows Terminal Preview v0.3.2142.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
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-Tag-Fix Product-Terminal Resolution-Fix-Committed
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#1897
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?