Cascading settings need to much overriding to get rid of defaults

[blami]

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.

[bitcrazed]

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.

[blami]

@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.

[atimholt]

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.

[DHowett-MSFT]

devastating

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

[DHowett-MSFT]

for this exact reason

[atimholt]

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

[zadjii-msft]

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.

[atimholt]

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.

[blami]

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.

[DonOregano]

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.

[zadjii-msft]

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

[ghost]

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!