Impossible to input Japanese

[JugglerShu]

Now to input japanese is not possible with XVim. I do not know the reason but this might be a result of changing of NSEvent to KeyStroke.

[tomlu]

I would love to look into this but it's hard because I can't really input Japanese myself.

What I would do to debug it is enter insert mode and put a breakpoint on [XVimWindow handleKeyEvent] as well as [XVimKeyStroke toEvent]. There must be some difference between the input and output event.

[KindleL]

the same problem with chinese

[tomlu]

Perhaps Japanese and Chinese uses more than one character per key event?

Could someone debug into it and feed me some data? Please put a breakpoint in keyStrokeOptionsFromEvent while inputting some Japanese/Chinese and paste the output of the description of the "event" local variable.

[JugglerShu]

Yes. Japanese or Chinese need more than one type to fix the actual input text.

I found following comment. http://www.cocoabuilder.com/archive/cocoa/152887-nstextview-keydown-question.html

It says if we do not handle keyDown method override carefully it breaks input system for Japanese or Chinese.

I wonder if we had any changis in keyDown method. (I confirmed that there was no problem with previous version about 1 month ago )

I logged the event object. -----Japanese Input OFF----- NSEvent: type=KeyDown loc=(0,824) time=662607.5 flags=0x100 win=0x401a555a0 winNum=82241 ctxt=0x0 chars="a" unmodchars="a" repeat=0 keyCode=0 -----Japanese Input ON----- NSEvent: type=KeyDown loc=(0,824) time=662669.8 flags=0x100 win=0x401a555a0 winNum=82241 ctxt=0x0 chars="a" unmodchars="a" repeat=0 keyCode=0

I can't see any change. Sorry if my guess is not write.

I think its a little difficult to debug with out Japanese input env. So if you think its too time consuming let it leave to me. ( I'll do it after fixing current another problem)

(4/10/12 5:14 PM), tomlu wrote:

Perhaps Japanese and Chinese uses more than one character per key event?

Could someone debug into it and feed me some data? Please put a breakpoint in keyStrokeOptionsFromEvent while inputting some Japanese/Chinese and paste the output of the description of the "event" local variable.

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/120#issuecomment-5041013

[tomlu]

The problem has to be that I'm throwing away some information from the NSEvent -> KeyStroke -> NSEvent pipeline. I essentially just keep the first character + (shift / control / option / command).

The reason the information is thrown away is that for key mapping I can't reconstruct more information from something like .

If you debug it, great, thanks heaps. Could I ask that you let me know what the problem is before committing it so I can make sure it will still work with key mapping? You could maybe push it to a branch first that I can check out?

[JugglerShu]

I made a temporal fix at branch JapaneseInputHandling. It just save an NSEvent to use in XVimNormalEvaluator. The fact that this fixes the problem means we lost some information in NSEvent when converting to KeyStroke.

I'll find what it the information needed.

(4/10/12 6:03 PM), tomlu wrote:

The problem has to be that I'm throwing away some information from the NSEvent -> KeyStroke -> NSEvent pipeline. I essentially just keep the first character + (shift / control / option / command).

The reason the information is thrown away is that for key mapping I can't reconstruct more information from something like.

If you debug it, great, thanks heaps. Could I ask that you let me know what the problem is before committing it so I can make sure it will still work with key mapping? You could maybe push it to a branch first that I can check out?

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/120#issuecomment-5041707

[JugglerShu]

It looks that its not possible to create original NSEvent from saved values. I created new NSEvent copied from original NSEvent which does not cause problem and pass the event into the keyDown: and it cause a problem(can't input Japanese).

So what I think is that the approach reconstructing NSEvent is not good now. We should keep NSEvent somewhere to use later.

Let me know if you have any comment on this approach.

(4/10/12 6:03 PM), tomlu wrote:

The problem has to be that I'm throwing away some information from the NSEvent -> KeyStroke -> NSEvent pipeline. I essentially just keep the first character + (shift / control / option / command).

The reason the information is thrown away is that for key mapping I can't reconstruct more information from something like.

If you debug it, great, thanks heaps. Could I ask that you let me know what the problem is before committing it so I can make sure it will still work with key mapping? You could maybe push it to a branch first that I can check out?

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/120#issuecomment-5041707

[tomlu]

Well I have to reconstruct NSEvents when they come from a key map because then I don't have one - all I've got at that point is some text like .

It is very strange that completely reconstructing the NSEvent does not work. If that is the case then there must be some subclassing going on that we aren't privy to.

I could try attaching the NSEvent to the key stroke and if nothing touches it I'll pass it through unchanged. I'll have something for you shortly.

[JugglerShu]

Yea I have just noticed about keyremapping thing. It also cause a problem for recordings?

I think some values in NSEvent is set by NSEvent class method. Can you see "window" variable in NSEvent? I could not set it when creating new NSEvent? (I set windowNumber correctly ). That is one of the difference. I changed the value from debugger but did not work.

Hm... We need more precise knowledge of process for text input.

And this is just a note: what I feel is that hooking keyDown: does not enough to do all the thing we want. Especically when we want to record inserted text in Japanese env. "insertText:" is also a candidate to hook to know what it the acutal input when in Japanese env. And this is needed when we really want to record inserted text.

(4/10/12 6:03 PM), tomlu wrote:

The problem has to be that I'm throwing away some information from the NSEvent -> KeyStroke -> NSEvent pipeline. I essentially just keep the first character + (shift / control / option / command).

The reason the information is thrown away is that for key mapping I can't reconstruct more information from something like.

If you debug it, great, thanks heaps. Could I ask that you let me know what the problem is before committing it so I can make sure it will still work with key mapping? You could maybe push it to a branch first that I can check out?

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/120#issuecomment-5041707

[tomlu]

With insertText we lose the modifier keys which are necessary both for key mapping and picking the right selectors. I think recording input is done via just copying the text so we might be ok, we'll see.

[tomlu]

How did this go? Is the issue fixed?

[JugglerShu]

Yes it is fixed. Thank you.