macOS: alt+i always inserts '^' character

[AriaMinaei]

• VSCode Version: 1.19.1 & 1.20.0-insider (f9115349ef09cfef2bed669680d10ac58b490dce)
• OS Version: macOS Sierra 10.12.6

Steps to Reproduce:

1. Assign keyboard shortcut "option+i" to a command such as 'Toggle Sidebar Visibility' or 'Go to Definition':
2. Try the shortcut in the editor. Sometimes the shortcut works (correct behavior), other times, the 'ˆ' character is put in the text without the command working (incorrect behavior), and sometimes the command works but the 'ˆ' character is also inserted (incorrect behavior).

Reproduces without extensions: Yes

22664 & #22894 might be relevant.

---

2022.12: Edited to add the upstream link:

Upstream issue: https://bugs.chromium.org/p/chromium/issues/detail?id=887519

[alexdima]

The root cause is the when condition associated with the keybinding.

The default keybinding for go to definition is bound only when editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor. When you edit/associate option+i with it, it will create a new keybinding rule that follows the same condition.

editorHasDefinitionProvider is a dynamic context key which depends on the file you are currently editing and the set of extensions you have installed. For example, if you have an extension (built in or installed from the marketplace) that implements the goto definition functionality for the current programming language, the key editorHasDefinitionProvider will be set.

Out of the box:

• TypeScript, JavaScript, CSS will have such a definition provider
• a plain text file does not have a definition provider

In your case, I believe you would want the keybinding option+i to always be considered, so you can do the following in your keybindings.json:

BEFORE:

    {
        "key": "alt+i",
        "command": "editor.action.goToDeclaration",
        "when": "editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor"
    },
    {
        "key": "f12",
        "command": "-editor.action.goToDeclaration",
        "when": "editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor"
    }

AFTER:

    {
        "key": "alt+i",
        "command": "editor.action.goToDeclaration",
        "when": "editorTextFocus && !isInEmbeddedEditor"
    },
    {
        "key": "f12",
        "command": "-editor.action.goToDeclaration",
        "when": "editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor"
    }

[AriaMinaei]

Thanks for the explanation @alexandrudima, but the workaround doesn't work, and the bug happens regardless of any command/when combination, meaning if I bind any other action to alt+i, it'll insert the ˆ character.

[alexdima]

Indeed, I can reproduce and get the circumflex character too when e.g. binding alt+i to toggle line comment:

{
    "key": "alt+i",
    "command": "editor.action.commentLine",
    "when": "editorTextFocus && !editorReadonly"
}

[alexdima]

This is also reproducible when in the Search Viewlet for example, and using the following binding:

{
        "key": "alt+i",
        "command": "toggleSearchWholeWord",
        "when": "searchInputBoxFocus && searchViewletVisible"
}

it is just weird that e.preventDefault() does not prevent the cirumflex character from appearing:

[alexdima]

The same happens for alt+` (#41590)

[alexdima]

I can reproduce in Chrome and have filed https://bugs.chromium.org/p/chromium/issues/detail?id=887519

[therealpeterhua]

I see similar behavior with alt+u and alt+n, where they will always insert ¨ and ˜ in addition to performing their bound command, even with no "when" criteria specified.

[alexdima]

@therealpeterhua This is a confirmed upstream bug, if you want to increase its visibility, I suggest you also try those out in Chrome and comment with your findings at https://bugs.chromium.org/p/chromium/issues/detail?id=887519

[kiranpoojary]

after using :
[ {doc1}, {doc2}, ... {docN} ]

Solved my problem

[alexdima]

The same happens for alt + e (#108478)

[alexdima]

Similar issue with shift+option+f on the ABC - India keyboard layout (#97166)

[chinaran]

https://stackoverflow.com/questions/11876485/how-to-disable-generating-special-characters-when-pressing-the-alta-optiona It works for me to use another input sources(not default ABC) on macos.

[codebysandwich]

alt - n insert ˜ too alt - m can work as expected

[wrinkledeth]

@codebysandwich , did you ever find a solution? This is really bothering me as I would like to be able to use alt+n as well, but keep getting a ˜character

[codebysandwich]

@codebysandwich , did you ever find a solution? This is really bothering me as I would like to be able to use alt+n as well, but keep getting a ˜character

i'm sorry about that, i used ⌃ + ⌥ + n instead of ⌥ + n :(

[jrdodds]

The macOS option key (⌥) is used for special characters, symbols, and accents. The macOS option key bindings and Windows alt key binding are not equivalent. Simply mapping Windows alt key bindings to macOS option key bindings will conflict with existing macOS option key bindings. Many of the issues tracked here are key binding conflicts.

The Keyboard Viewer with a US keyboard shows as follows without any modifier key pressed:

and with the option key pressed:

[greneholt]

This StackOverflow answer explains how to completely prevent Option+key from producing special characters, allowing you to use these combinations for shortcuts in VS Code and various other editors.

In short:

1. Download this QWERTY keyboard layout file (or generate one yourself using the instructions in the linked answer).
2. Move it to ~/Library/Keyboard Layouts/
3. Go to System Settings > Keyboard > Text Input > Input Sources > Edit.
4. Click + in the bottom left, scroll to the bottom of the list on the left and select Others then select QWERTY no option and click Add.
5. Either delete your existing layout (probably called U.S.) or just switch to the QWERTY no option layout using the input-source select in the menu bar.

[jrdodds]

The selected input source is global for the user. It's not limited to VSCode. I'd suggest keeping the existing keyboard so that it is possible to switch (in the input menu) to a keyboard that supports normal option functionality, if ever needed.

[jimeh]

So, yes, macOS does insert special characters on alt/option+, rather than trigger special keys. However, not in all apps. Emacs for example handles all those bindings correctly, and both Terminal and iTerm have settings that allow them to capture alt/option keybindings and pass them to whatever you have running in a terminal, instead of inserting the character macOS would normally insert.

So macOS definitely exposes some mechanism for apps to capture alt/option keybings. I don't know enough about macOS development myself to say what that mechanism is, but I know it's possible as other apps do it.

Hence it would be nice if we could see VSCode support it too.

[greneholt]

Agreed, but until Chromium deals with the upstream issue I don't think that will be possible. This workaround at least allows those who don't need extended character sets to use these shortcuts.

[forivall]

I'm hitting this issue with dead keys overriding the keyboard shortcuts defined by the dance extension. I've had to resort to the same solution as @codebysandwich. Interestingly, the keyboard shortcuts "recording keys" mode is able to capture the key combination, so there could be a workaround by using the same key capture mechanism used there.

[diminutivesloop]

Could there not be an option similar to terminal.integrated.macOptionIsMeta but that applies globally? When I enable that option I can type shortcuts like option+c in the terminal and it doesn't output 'ç' like it does elsewhere. I use the Codeium extension and a bunch of their default shortcuts conflict with the special character shortcuts, and it would be nice for those to just work without having to override them.

[diminutivesloop]

Although to be fair terminal.integrated.macOptionIsMeta only works for some special character shortcuts and doesn't appear to address option+i.