Skip to content
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

Fix macOS input method #1586

Closed
wants to merge 8 commits into from
Closed

Conversation

blahgeek
Copy link
Contributor

@blahgeek blahgeek commented May 2, 2019

  1. Backspace now works with input method. Fixes Backspace not working properly in Chinese input on macOS. #1461
  2. Pre-edit texts from input method are correctly displayed.
  3. Input method dialog now follows the cursor.

Screencast: https://youtu.be/R4ZfSM3KE0Y

Screen Shot 2019-05-02 at 16 39 43

@xiaket I believe you would be interested in this, could you please give it a test?

@xiaket
Copy link

xiaket commented May 2, 2019

I can confirm that the Chinese input method is working as intended, thank you very much.

I even ventured to try Japanese input method, and the position of the input window can now correctly follow the cursor. Looks like it's all working.

Good job!

@Luflosi
Copy link
Contributor

Luflosi commented May 2, 2019

This pull request breaks a little thing for me.
On my german keyboard layout under the escape key, there is a ^ key. If I press it and then the space bar afterwards, I get ^. Pressing a instead of space gives me â, e gives me ê and so on. Pressing ^ twice has the same effect as pressing it once, pressing space and pressing ^ again. In most programs the ^ has an underline or is otherwise marked as being special as long as I didn't press the second key. In kitty, instead of the ^ with the underline, nothing is displayed. But that didn't really bother me since the functionality is there, even if the ^ isn't shown.
With this pull request, pressing ^ twice will print ^ twice, with the first ^ being highlighted. Pressing space now should leave the first ^ intact and "finalise" the second ^ so that there are two ^. But instead there are now three ^ with the cursor position after the second ^ and the first ^ one cell too early. The cursor position should be one cell after what it is now. Now the cursor position is out of sync with what my shell thinks it should be.
Here are a couple screenshots:
Without the pull request:
After starting kitty and after pressing ^:
orig 1
After pressing ^ again:
orig 2
After pressing space:
orig 3
With the pull request:
The screenshot after starting kitty and after pressing ^ looks the same as above, so I didn't upload it again.
After pressing ^ again:
new 2
After pressing space:
new 3

These screenshots were made with three lines visible in kitty. With two lines, the first ^ in the last screenshot does not appear for some reason.

@kovidgoyal
Copy link
Owner

You can replicate @Luflosi issue without a german keyboard by using the US -International keyboard layout and pressing the ` key two times followed by space.

@kovidgoyal
Copy link
Owner

@blahgeek rather than ignroing pre-edit text on dead keys, wouldn't it be better to send it to kitty, so that it displays and then clear it when the compose sequence is over (which you can detect by check the value of deadKeyState before and after the call to UCKeyTranslate?

@blahgeek
Copy link
Contributor Author

blahgeek commented May 3, 2019

Thanks for your feedback.

@Luflosi please test the updated code, it should fix your issue.

I tried to get the pre-edit ^ character to display, by showing markedText on dead key state. It would work well on key sequences like ^ a (it would first display highlighted "^", then replaced by "â", like in other apps), but I cannot get it working for key sequences like ^ ^ (which should first display highlighted "^", then replaced by a real "^", with another highlighted "^" remaining). The main issue here is that, calling _glfwInputKeyboard with state = 1 (draw pre-edit text) immediately after calling it with state = 0 (insert 0) would not work. The reason seems to be it not updating cursor positions synchronously. @kovidgoyal any thoughts?

@blahgeek
Copy link
Contributor Author

blahgeek commented May 3, 2019

Or maybe I can treat all chars (even those from insertText) as pre-edit texts before dead key state returns to 0.

@kovidgoyal kovidgoyal closed this in f0c663d May 3, 2019
@kovidgoyal
Copy link
Owner

I have committed an implementation of highlighting during compose sequences as well. Let me know if there are any issues.

@blahgeek
Copy link
Contributor Author

blahgeek commented May 3, 2019

Try press two "^" using swiss german input source. Your implementation would only only show one commited "^", the correct behavior should be showing one commited "^", and another pre-edit "^".

I have another implementation on this branch, check it out blahgeek@2f1ed41

@blahgeek
Copy link
Contributor Author

blahgeek commented May 3, 2019

fyi: I tested with this ("^" is in the left of backspace, which is "=" in us keyboard):
Screen Shot 2019-05-03 at 16 32 57

@kovidgoyal
Copy link
Owner

I tried it with the key in the US international layout. Pressing it twice gives you one and does not display the second `, even though it
is in pre-edit mode. But iTerm behaves the same way, so i am fine with
kitty behaving like that as well.

@kovidgoyal
Copy link
Owner

I tried it with = in the swiss-german layout and there also iTerm
behaves the same. Both kitty and iTerm "swallow" the second ^

@blahgeek
Copy link
Contributor Author

blahgeek commented May 3, 2019

Try TextEdit.app

@kovidgoyal
Copy link
Owner

I think iTerm is a better example to follow than TextEdit for a terminal
emulator.

@kovidgoyal
Copy link
Owner

Oh and let me clarify, it's not that I think the current behavior is correct, it's obviously not. But given that iTerm does it too, it cant be a big deal. And since the API limitations of cocoa mean that we cant solve this robustly, doing major surgery on the text handling makes me nervous, as it is likely to break something else.

@Luflosi
Copy link
Contributor

Luflosi commented May 4, 2019

iTerm behaves differently for me, it doesn't "swallow" the second ^.
Initial window:
screenshot 1
After pressing ^:
screenshot 2
After pressing ^ again:
screenshot 3
After pressing space:
screenshot 4

@Luflosi
Copy link
Contributor

Luflosi commented May 4, 2019

The same behaviour happens with ´ and `.

@blahgeek
Copy link
Contributor Author

blahgeek commented May 5, 2019

@Luflosi have you tried this commit? blahgeek@2f1ed41

@Luflosi
Copy link
Contributor

Luflosi commented May 5, 2019

blahgeek/kitty@2f1ed41 looks almost like I would expect it:
Initial window:
screenshot 1
After pressing ^:
screenshot 2
After pressing ^ again, the first character shouldn't be marked:
screenshot 3
After pressing space:
screenshot 4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Backspace not working properly in Chinese input on macOS.
4 participants