Zed breaks well-established special character input conventions

[grzegor]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Zed should respect globally established character input conventions by default. Universally, right alt key with [a-zA-Z0-9] is used as a special character input method in many languages, usually diacritics like ó, ż, ą, ź or other locally significant symbols like € and their key combination should not be overwritten without explicit user intervention as this breaks expected core interaction with any piece of software.

There's already a closed issue because of this behavior (#6422), but it's only to give the ability to opt-out of it (disable the already conflicting keymap selectively by the user), where making any assumptions on alt-anything, especailly in text editors, should really be an opt-in, even if they're targeted as code editors, there are always use cases of localized strings, comments, documentation etc.

Otherwise, there's going to be a lot more of #6422 duplicates from people using languages that utilize alt-h,f,d,v,b and previously mentioned alt-z that you overwrite out of the box.

Environment

macOS

If applicable, add mockups / screenshots to help explain present your vision of the feature

Other software resolves it by either introduce additional modifier key alongside alt (e.g. alt+cmd+z) or use only left alt as an application modifer key in the default configuration.

[mrnugget]

Hey @grzegor! Can you clarify on what exactly Zed should support and doesn't right now? A keybinding is overwriting opt-z?

[grzegor]

Yes, In my case (Polish diacritics) out of the alt-h,f,d,v,b,z only the "z" is problematic, as it should output "ż" character while it turns line wrapping on/off instead. There are many other languages that also use alt for their different diacritics, including, but probably not limited to:

alt-h - esperanto, arabic, turkish alt-f - irish and scottish accents alt-d - czech, slovak, turkish, serbian, croatian alt-v - nothing major language-wise, but some people use that combination to output the "√" symbol, but since most other mathemathical symbols requires different method to input characters anyway overriding this is probably acceptable alt-b - irish, some african languages alt-z - polish, czech, slovenian

As you can see, some are used by major languages

[N8th8n8el]

Also alt-u for german (ü, ö, ä) on international keyboard layouts.

[mrnugget]

Okay, got it! So the problem is not that these keys don't work, but that they're overwritten by default -- do I have that right?

Because I can use opt-u, opt-o, opt-e, opt-c, and others without any problems in Vim mode.

[Moshyfawn]

I'm not entirely sure it's the same problem, but it feels pretty close to what I've been able to reproduce.

Re-mapping the cmd-w keymap to ctrl-w causes the problem that all non-Latin (?) input sources don't register the command.

https://github.com/zed-industries/zed/assets/16290753/86033de9-e9e3-4c74-863f-ae1043bdaa2c

[grzegor]

Okay, got it! So the problem is not that these keys don't work, but that they're overwritten by default -- do I have that right?

Yes. Opt-z is overwritten by default. This is breaking some languages.

Because I can use opt-u, opt-o, opt-e, opt-c, and others without any problems in Vim mode.

AFAIK neither of those keys (opt + u, o, e or c) are overwritten by Zed's default keymap, they're currently not an issue (unless you'll start overwriting them at some point, in that case you'll have a bunch of angry germans in your comments).

I listed previously all opt + [key] combos you currently bind by default and with which languages they collide.

Also I just want to note this is not a deal-breaker, as you can manually unbind them, but it's just something you definitely should avoid in your default configuration. At the end of the day that's THE main purpose of text editors - write text. And currently you're limiting that absolute core functionality of writing text in some languages. I don't need 120Hz refresh, I need to write things and only if that's working, then I want all those QoL improvements you provide.

[inputsh]

Had the same issue with opt-b, which should print { on my keyboard layout (Bosnian, not listed above), but doesn't. To close the curly brackets, it's opt-n, which works out-of-the-box. So, by default, I could close the curly brackets, but not open them.

Step-by-step instructions in case someone needs them:

1. Open the default keymap from the command palette.
2. Find the binding you're trying to get rid of. In my case, it was mapped like this: "alt-b": "editor::MoveToPreviousWordStart" (note: alt = opt)
3. Open the (non-default) keymap from the command palette and add something similar to this:

[
  {
    "context": "Editor",
    "bindings": {
      "alt-b": null
    }
  }
]

I reverted back to another editor multiple times before I bothered to look up how to fix it. It's not a big hassle, but at the same time I can't remember having to do anything manually in any other app for my preferred keyboard layout to just work.

[ConradIrwin]

Another example reported via in-app-feedback: @ is typed with alt-q on a Turkish layout