New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't type Chinese with IME in macOS #910

Closed
cissusnar opened this Issue Sep 7, 2018 · 17 comments

Comments

Projects
None yet
4 participants
@cissusnar

cissusnar commented Sep 7, 2018

can't type Chinese with IME in macOS.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Sep 7, 2018

add

macos_option_as_alt no

in your kitty.conf

@kovidgoyal kovidgoyal closed this Sep 7, 2018

@cissusnar

This comment has been minimized.

cissusnar commented Sep 7, 2018

not work.
Blender has same problem, IME(input method engine) need special treatment.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Sep 7, 2018

Well, IME is the responsibility of GLFW the windowing toolkit kitty uses. I patched GLFW to support IME on linux but that is about as far as I am willing to go. You are welcome to patch GLFW for IME on macOS, but it is not something I am willing to do.

@cissusnar

This comment has been minimized.

cissusnar commented Sep 7, 2018

OK, thank you for the response, I'll try it if I have time.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Sep 7, 2018

See #469 for details on how I did it for linux

@blahgeek

This comment has been minimized.

blahgeek commented Sep 9, 2018

Hi @kovidgoyal , I did some debugging and found that simply removing the following code seems work for me:

diff --git a/glfw/cocoa_window.m b/glfw/cocoa_window.m
index 5f8b355a..80f8e5b6 100644
--- a/glfw/cocoa_window.m
+++ b/glfw/cocoa_window.m
@@ -830,9 +830,9 @@ is_ascii_control_char(char x) {
             // cmd+a will result in the text a.
             [self interpretKeyEvents:[NSArray arrayWithObject:event]];
             debug_key(@"char_count: %lu cocoa text: %s\n", char_count, format_text(_glfw.ns.text));
-            GLFWbool cocoa_wants_to_insert_text = !is_ascii_control_char(_glfw.ns.text[0]);
-            _glfw.ns.text[0] = 0;
-            if (char_count && cocoa_wants_to_insert_text) convert_utf16_to_utf8(text, char_count, _glfw.ns.text, sizeof(_glfw.ns.text));
         } else {
             window->ns.deadKeyState = 0;
         }

For example, if I need to type "我" using PinYin input method, I'd type w, o, <SPACE>. Before making this change, the first two strokes are handled correctly (dialog box of input method shows up), but the <SPACE> does not perform the selection, instead a literal space is entered.

I found that, upon the <SPACE> being entered, _glfw.ns.text contains expected character "我" in UTF-8, but text contains a literal space. So I deleted those three lines and it does work for me.

I have zero experience with cocoa programming, I'm not sure how this should work. Could you please take a look at this? Thanks!

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Sep 9, 2018

Your patch will break processing of cmd+key as those lines of code are meant to handle. From looking at the code, it seems like the correct procedure would be to detect a state transition from handling dead keys to dead key handling being complete. If that state transition happened for the current key, then you can bypass those three lines. To track the state transition you would need to check deadKeySTate before calling UCKeyTranslate and see if it changes from non-zero to zero.

@xiaket

This comment has been minimized.

xiaket commented Oct 7, 2018

Hi @kovidgoyal ! I was poking around this issue today and I can confirm that the patch provided by @blahgeek works for me. As you've mentioned this will break cmd+key processing, but in my tests, key mapping defined in config files works flawlessly. Can you please elaborate on the breaking of cmd+key processing?

I can see that those three lines were added to implement dead key support on macOS. From what I've learned from wikipedia, the dead key was used to modify an existing character. However, this does not happen in the input of Chinese characters.

And as always, thanks for this great project!

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Oct 7, 2018

Yeah but it happens in other keyboard layouts. For dexample, typing cmd+a will get you an a with accents using the us layout. As I said the way to fix this is to detect the transtion of deadKeyState.

@xiaket

This comment has been minimized.

xiaket commented Oct 7, 2018

Thanks for the quick reply. I had zero exposure to objc and I know this could be an ugly hack but does this detection of space/tab make sense to you? Since Chinese/Japanese input methods use these char to signify the end of CJK input AFAIK.

            if !(_glfw.ns.text[0] == 32 || _glfw.ns.text[0] == 9) {
                GLFWbool cocoa_wants_to_insert_text = !is_ascii_control_char(_glfw.ns.text[0]);
                _glfw.ns.text[0] = 0;
                if (char_count && cocoa_wants_to_insert_text) convert_utf16_to_utf8(text, char_count, _glfw.ns.text, sizeof(_glfw.ns.text));
            }
@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Oct 7, 2018

That might solve it for CJK in particular, but is not a general solution, since you cannot rely on space having special meaning in all keyboard layouts. It might well break some layout where space is supposed to be part of compose sequences. THere needs ot be some layout dependent way of detecting when a compose sequence is finished, as I said in myprevious post, that seems to be looking at transitions of deadKeyState,

@blahgeek

This comment has been minimized.

blahgeek commented Oct 21, 2018

@kovidgoyal So sorry to bother you again but I still don't get it. Can you please show us some examples which my patch would break? You mentioned "cmd+a" should get you an "a" with accents in us layout but I actually don't get it, isn't "cmd+a" means "select all"? Or did you mean "alt+a", or from the wikipedia, "alt+e" followed by "a"? Both cases still works with my patch.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Oct 21, 2018

text comes from UCKeyTranslate. If you press cmd+a text will contain "a". But kitty should not output a in this case. With your patch, it will.

@blahgeek

This comment has been minimized.

blahgeek commented Oct 21, 2018

Seems ok to me 🤔
https://youtu.be/Cf9nid0sNzg

@xiaket

This comment has been minimized.

xiaket commented Oct 21, 2018

Seems ok to me 🤔
https://youtu.be/Cf9nid0sNzg

I can confirm I did exactly the same tests. Moreover, Alt-A and Cmd-A were defined as keyboard shortcuts in my configuration and they were working ok. So the only thing changed by the patch is the enablement of Chinese input.

As a side note, @blahgeek, I'm afraid this patch is not a final solution, please see the last paragraph of my blog article https://blog.xiaket.org/2018/kitty-chinese-ime.html. For the convenience of @kovidgoyal, I'll briefly describe the problem here:

It turns out the handling of backspace/delete is flawed in the patch provided by @blahgeek earlier. For example, if we have 你好 before the cursor and we are about to enter 世界. To do that, we use the Chinese IME and enter shijie and that's about it. However, if we had made a mistake and entered shik, what we need to do is to hit delete. what we expect to happen with this delete is, k is removed and we continue to enter jie. That is indeed what happened, but a side effect of that delete is, the character before the cursor is removed. This is not really a deal breaker, but this behavior is different from what we(the Chinese) would expect.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Oct 21, 2018

Interesting, I cannot reproduce the problem either on mojave, which means apple likely fixed UCKeyTranslate sometime since that code was written.

@kovidgoyal

This comment has been minimized.

Owner

kovidgoyal commented Oct 21, 2018

Given that I am ok with removing those three lines. as for the problem with delete, you would simply need to detect if deadKeyState != 0 before the delete key is pressed and if so, special case handling of it.

@kovidgoyal kovidgoyal reopened this Oct 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment