starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Cascading settings need to much overriding to get rid of defaults #4637

New Issue
Closed
opened 2026-01-30 23:52:30 +00:00 by claunia · 12 comments
claunia commented 2026-01-30 23:52:30 +00:00
Owner
Copy Link

Originally created by @blami on GitHub (Oct 24, 2019).

Description of the new feature/enhancement

Currently "defaults" (including profiles and keybindings) are always applied and merged with "profiles.json". I have zero overlap between default and custom keybindings because I use default prefix (ctrl+shift) inside different application. In new version of Terminal, if I don't override all those to null I have unwanted side effects (specially if that app passes keybindings through and Terminal gets them).

Also I don't want to have certain profiles visible but GUIDs are different across machines so on each machine where I use Terminal I have to checkout my dotfiles (including Terminal config), inspect defaults file and then override (hide) those GUIDs.

Proposed technical implementation details (optional)

Merge (cascading) should be optional. If disabled defaults should be used one-time to create profiles.json.

Originally created by @blami on GitHub (Oct 24, 2019). # Description of the new feature/enhancement Currently "defaults" (including profiles and keybindings) are always applied and merged with "profiles.json". I have zero overlap between default and custom keybindings because I use default prefix (ctrl+shift) inside different application. In new version of Terminal, if I don't override _all_ those to null I have unwanted side effects (specially if that app passes keybindings through and Terminal gets them). Also I don't want to have certain profiles visible but GUIDs are different across machines so on each machine where I use Terminal I have to checkout my dotfiles (including Terminal config), inspect defaults file and then override (hide) those GUIDs. # Proposed technical implementation details (optional) Merge (cascading) should be optional. If disabled defaults should be used one-time to create profiles.json.
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-30 23:52:31 +00:00
claunia commented 2026-01-30 23:52:31 +00:00
Author
Owner
Copy Link

@bitcrazed commented on GitHub (Nov 1, 2019):

Thanks for your feedback and appreciate your views. However, I don't quite follow what your proposed solution for your use-case is. We have to provide default key-mapping for many common and popular chords to expected actions, otherwise the Terminal won't be useful to most users.

If those key-mappings don't meet YOUR needs, you'll need to unbind/remap the defaults that you don't want.

While in your case, this means you may have to unmap more defaults than most, this is a necessary byproduct of Terminal providing sane defaults for most users, no?

Regarding GUID's: You can omit GUID's completely if you wish - your Terminal instances will then just auto-generate GUIDs internally, which it uses to differentiate one profile from another.

@bitcrazed commented on GitHub (Nov 1, 2019): Thanks for your feedback and appreciate your views. However, I don't quite follow what your proposed solution for your use-case is. We have to provide default key-mapping for many common and popular chords to expected actions, otherwise the Terminal won't be useful to most users. If those key-mappings don't meet YOUR needs, you'll need to unbind/remap the defaults that you don't want. While in your case, this means you may have to unmap more defaults than most, this is a necessary byproduct of Terminal providing sane defaults for most users, no? Regarding GUID's: You can omit GUID's completely if you wish - your Terminal instances will then just auto-generate GUIDs internally, which it uses to differentiate one profile from another.
claunia commented 2026-01-30 23:52:31 +00:00
Author
Owner
Copy Link

@blami commented on GitHub (Nov 5, 2019):

@bitcrazed Thanks for response, I completely understand that reasonable defaults need to be provided.

My problem is that I need to follow what you guys added/changed and remove that in my settings overlay pro-actively. It would be ideal if there was a general config switch e.g. addDefaultKeyBindings: I can set to false so I'm sure that only my own keybindings will be used and not weird mixture of in-time changing defaults and my own.

As for GUIDs, thank you, I didn't know that.

@blami commented on GitHub (Nov 5, 2019): @bitcrazed Thanks for response, I completely understand that reasonable defaults need to be provided. My problem is that I need to follow what you guys added/changed and remove that in my settings overlay pro-actively. It would be ideal if there was a general config switch e.g. ```addDefaultKeyBindings:``` I can set to ```false``` so I'm sure that only my own keybindings will be used and not weird mixture of in-time changing defaults and my own. As for GUIDs, thank you, I didn't know that.
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@atimholt commented on GitHub (Mar 10, 2020):

Defaults can yield surprising and devastating results when there is no trivial way to turn them off.

Take, for example, a user who uses Vim keybindings in *NIX command lines. Ctrl-w is used to delete the previous word, but trying this in Windows Terminal invariably closes the current tab without warning, which is a show-stopping problem to have. No application should punish a fully-supported use case by default.

@atimholt commented on GitHub (Mar 10, 2020): Defaults can yield surprising and devastating results when there is no trivial way to turn them off. Take, for example, a user who uses Vim keybindings in *NIX command lines. Ctrl-w is used to delete the previous word, but trying this in Windows Terminal invariably closes the current tab without warning, which is a show-stopping problem to have. No application should punish a fully-supported use case by default.
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 10, 2020):

devastating

Ctrl+W hasn’t been bound by default since version 0.3, about half a year ago.

@DHowett-MSFT commented on GitHub (Mar 10, 2020): > devastating <kbd>Ctrl+W</kbd> hasn’t been bound by default since version 0.3, about half a year ago.
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 10, 2020):

for this exact reason

@DHowett-MSFT commented on GitHub (Mar 10, 2020): _for this exact reason_
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@atimholt commented on GitHub (Mar 10, 2020):

Odd, it just happened to me today. That’s why I’m here.

@atimholt commented on GitHub (Mar 10, 2020): Odd, it just happened to me today. That’s why I’m here.
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 10, 2020):

If you installed the Terminal immediately when we first released, then you probably still have ctrl+w bound in your settings - it should be trivial to change that line in your profiles.json file.

@zadjii-msft commented on GitHub (Mar 10, 2020): If you installed the Terminal immediately when we first released, then you probably still have <kbd>ctrl+w</kbd> bound in your settings - it should be trivial to change that line in your `profiles.json` file.
claunia commented 2026-01-30 23:52:32 +00:00
Author
Owner
Copy Link

@atimholt commented on GitHub (Mar 12, 2020):

I meant it merely as an example—it’s the kind of thing that’s only possible if defaults aren’t a cohesive “thing”, and are instead scattered and islands unto themselves. If a user intends to use their own mappings for everything, for example, there’s no telling what new defaults will arise later that add surprise to their experience.

This wouldn’t be the case for many pieces of software, but a terminal is supposed to be able to pass unmapped key combinations through unchanged to other tools that have their own mappings.

@atimholt commented on GitHub (Mar 12, 2020): I meant it merely as an example—it’s the kind of thing that’s only possible if defaults aren’t a cohesive “thing”, and are instead scattered and islands unto themselves. If a user intends to use their own mappings for everything, for example, there’s no telling what new defaults will arise later that add surprise to their experience. This wouldn’t be the case for many pieces of software, but a terminal is supposed to be able to pass unmapped key combinations through unchanged to other tools that have their own mappings.
claunia commented 2026-01-30 23:52:33 +00:00
Author
Owner
Copy Link

@blami commented on GitHub (Mar 20, 2020):

I'd much more prefer standard UNIX approach where tool ships with default config file. You edit it, you exactly know what will happen. No surprises, no cascading settings.

@blami commented on GitHub (Mar 20, 2020): I'd much more prefer standard UNIX approach where tool ships with default config file. You edit it, you exactly know what will happen. No surprises, no cascading settings.
claunia commented 2026-01-30 23:52:33 +00:00
Author
Owner
Copy Link

@DonOregano commented on GitHub (Sep 4, 2020):

It would be awesome to be able to disable all key bindings. Currently I have to read a mile of documentation to find them all and disable them or set them to something I like.

@DonOregano commented on GitHub (Sep 4, 2020): It would be awesome to be able to disable all key bindings. Currently I have to read a mile of documentation to find them all and disable them or set them to something I like.
claunia commented 2026-01-30 23:52:33 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 7, 2022):

You know, I've come back to this thread after a few year now, and I think it's best served by #2205. We've been socializing a plan on that around the team for a while, but never had the time to write that into a proper spec. From that thread:

I think our unofficial plan has been to add support for "keymaps". This would follow the work for #1571 / #6899. Then, keymaps would contain objects which bind keys to various actions. The user could then just specify keymap: "foo" to replace all their keybindings with the ones in foo, no layering involved. Adding keys to actions directly would just update the "default" keymap, which is used when no keymap is specified.

I think for tracking purposes, it's best to just merge this with that thread. Thanks for the discussion all!

/dup #2205

@zadjii-msft commented on GitHub (Jan 7, 2022): You know, I've come back to this thread after a few year now, and I think it's best served by #2205. We've been socializing a plan on that around the team for a while, but never had the time to write that into a proper spec. From that thread: > I think our unofficial plan has been to add support for "keymaps". This would follow the work for #1571 / #6899. Then, `keymaps` would contain objects which bind keys to various actions. The user could then just specify `keymap: "foo"` to replace _all_ their `keybindings` with the ones in `foo`, no layering involved. Adding keys to actions directly would just update the "default" keymap, which is used when no `keymap` is specified. I think for tracking purposes, it's best to just merge this with that thread. Thanks for the discussion all! /dup #2205
claunia commented 2026-01-30 23:52:33 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 7, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jan 7, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
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 Issue-Feature Resolution-Duplicate
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#4637
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?