Confusing dialog: Disable other keymaps ('…') to avoid conflicts between keybindings?

[clozach]

The "Disable other keymaps" dialog has serious usability issues.

First there's ambiguity in what will happen if I click, "Yes"…so I never do. Is it saying that all keymaps other than Atom Keymap will be disabled? Or is it saying that Atom Keymap is the "other", and it's the one that will be disabled? Perhaps more importantly, if I make a mistake, how will I know how to fix it? What part of the settings will this affect? Is there a view that shows keymap conflicts that I can view before making this decision?

As it is, the path of least resistance while I'm busy trying to focus on getting work done has always been to just hit "No" and get on with my day. Which is probably lazy of me, but I suspect my psychology isn't too different from others in this regard.

Possibly-useful changes, from least-effort to most:

• Rewrite the message to explicitly lay out the consequences of choosing Yes
• Include details about how to change the setting in the future.
• Link to VS Code documentation explaining keymaps
• Correct the documentation, which references an apparently-obsolete "Show Conflicts". (It's apparently been re-labelled to "Show Same Keybindings"). Or does that text change contextually?
• Augment the docs with instructions for how to discover keybindings that directly conflict (as opposed to just being "same" but unconflicting)
• Best, but definitely not trivial: change the dialog to something like, Keymap conflict detected. Would you like to see the conflicts highlighted in the Keyboard Shortcuts editor?

[andig]

Reading #98 this sounds more like a vscode than a plugin issue?

[clozach]

Goodness, you're right. I must have lazily elided the sublime in vscode-sublime-keybindings. I'll repost over on #98 in case these ideas prove useful over there.

Thanks, @andig…and sorry for not replying sooner. 🥴