Keymap takes precedence over input methods(CJK IME)

[YinMo19]

Summary

Keyboard binding takes precedence over input methods(CJK IME)

(Sorry for my English level) As a CJK and Vim user, I LOVE zed. But I meet a problem when I just try jj -> escape.

[
  {
    "context": "vim_mode == insert",
    "bindings": {
      "j j": "vim::NormalBefore"
    }
  },
]

As the documents suggests, I use those code for this map. But the keymap take precedence over input methods, and I fail to input some chinese char begin with j.

In normal vim, I can type any Chinese content in insert mode, and all content will be blocked by the input method first, and then converted to Chinese in the input method before being input into the editor (I don't know if this is the case, at least from what I have observed?). You can watch the video below.

https://github.com/user-attachments/assets/8dc6abfb-cdaf-4e3a-a90b-5145792789f5

This is not the case when used in zed. There are many words beginning with j in Chinese, and if they cannot be typed, many people will have a lot of trouble when editing with zed.

https://github.com/user-attachments/assets/2bcc71af-5c03-423c-aae6-26fa600900dc

the chinese typed in video means If you type any other text then it is correct, but if you type (j text not)

I have noticed that there has been some discussion about Chinese input method and vim shortcut, but they are discussing that Chinese input method should not be higher than the shortcut key in normal mode (which is correct, because any Chinese input in normal mode is invalid). So typing directly in English can trigger the shortcut is fine)

Like:

• https://github.com/zed-industries/zed/issues/16813

but in insert mode we are typing Chinese, so blocking j is something that bothers me.

Finally, with great respect to all the zed contributors, the editor you designed and developed is really good!

Zed Version and System Specs

Zed: v0.180.2 (Zed) OS: macOS 14.6.1 Memory: 8 GiB Architecture: aarch64

[YinMo19]

has anyone mentioned this? I found another problem about this. Any Chinese char input in terminal will NOT implement with ENTER. I think the behavior of ime in both terminal and buffer should be same.

[probably-neb]

Seems like something with our wait-for-next-keystroke logic is conflicting with our IME handling. We likely need to pass on the keypress events as is if the keybind fails to be recognized after waiting for next keystroke as is common in vim style bindings. Thanks for reporting!

[YinMo19]

Yes, I know this is indeed a solution, but I think it might be better to make the input method superior to the keyboard events. Why not have the input method intercept the keyboard events first, and then allow the content that needs to be input to enter the editor buffer? I observed that almost all editors follow this kind of logic?

From another perspective, if we truly want keyboard input to go through zed before the ime , then consider the following scenario - I set up consecutive jk key presses, and after pressing, it will revert from insert to normal. However, in some input methods (in this case, Chinese won't, as no words will be continuously using jk) there might be a situation where the input "jksjak" is intercepted by zed first, triggering some effect, causing the remaining "sjak" to be input in normal mode. If the input method intercepts jksjak before zed, then jksjak will be spelled out as a certain word in the input method and then enter the buffer of zed.

Thank you for taking the time to look at my issue. I wish you a smooth life and all the best.

[tabuyos]

the same for me, and I found this #30393

[guopenghui]

Things are getting worse on my win10. I can't press backspace to delete input on ime.

https://github.com/user-attachments/assets/9b51666e-fc05-41b5-88b6-3b026318838c

[YinMo19]

Things are getting worse on my win10. I can't press backspace to delete input on ime.

Oh, that is really a disaster. I have unset the keybind of jj for escape, and nowadays things work fine on my macbook pro (15 Sequoia)

https://github.com/user-attachments/assets/da969333-02c3-450e-9a12-12f600e32415

has anyone mentioned this? I found another problem about this. Any Chinese char input in terminal will NOT implement with ENTER. I think the behavior of ime in both terminal and buffer should be same. i dont know why the ime behaviour differs, but terminal in the latest ver seems good now. maybe there are several fix in recent ver.

[flczcy]

Things are getting worse on my win10. I can't press backspace to delete input on ime.

PixPin_2025-06-28_02-21-10.mp4

same with win11

[JunkuiZhang]

@guopenghui @flczcy Not sure what IME you’re using on Windows, but I know some, i.e. Sogou, don’t follow the Windows IME spec and even hook certain system calls, which basically makes proper adaptation almost impossible.

[YinMo19]

This issue seems to need to remain open for a while. At least in the stable 0.198.6 version, the problem has become even more bizarre. Entering "jiben" will send "iben" to ime and leave a "j" and an "i" before and after the cursor respectively.

[guopenghui]

@JunkuiZhang I'm using Sogou Input Method. Previously, Sogou Input Method was working fine, but after a certain update, issues started to arise. Maybe it's this (https://github.com/zed-industries/zed/pull/32166)?

I don't fully understand how Sogou Input Method works, but since it's the most widely used input method in China, we should still find ways to support it?

[guopenghui]

Currently, I temporarily solve this issue by manually compiling and replacing this line during each update, otherwise it's almost impossible to use normally.

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older bugs that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and it will be kept open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, it will close automatically in 14 days. Thanks for your help!