Hi,
it is great that finally Japanese is shown correctly in TextMate but the input has some problems and differs from the rest of the system.
When I enter only one character like 私 (watashi), I type "watashi", hit space, select the character and hit enter. The final result is 私 and the cursor is set after the character. In TM2 the enter will delete the character, as if it is selected and do a line break.
When I enter a whole sentence, I press space when I am ready and the system will do some auto-conversion. Then I will get to to the first sentence-element and can press space to change the conversion to something different (loads of homonymes in Japanese). With cursor left and right I can go through the text elements and narrow the selection what a certain text element is with shift+left or widen it with shift+right. I end conversion-mode with pressing enter, when everything is in the state as I want it. When I press left or right in TM2 the conversion-mode ends and the cursor goes to the right but conversion-mode should only end after pressing enter (and only an extra enter should create the line-break).
Niels
I noticed this too. It's worth mentioning right now that you can still transliterate to kanji, then move the cursor to keep the character (instead of getting rid of it by pressing enter).
In normal Cocoa text fields, you do hit Enter to finish the transliteration, as Niels mentioned. It seems like in TextMate 2 that the text entered through Kotoeri is highlighted as it's entered, so pressing Enter replaces it with a newline.
2011/12/13 Niels Kobschätzki n.kobschaetzki@googlemail.com:
On 15 Dec 2011, at 03:33, Kevin Griffin wrote:
I noticed this too […]
Anyone having issues with an input mode please write tm-support@macromates.come with name of input mode and exact steps to reproduce + expected / actual results.
I am aware of issues, the problem for me is that there are 10 or so different input modes and they all have slightly different behavior and there is pretty much no documentation on how I should implement this — my fix for one of the Chinese input modes is what seems to have introduced this “return overwrites the glyphs”, but overtyping was required for the Chinese one.
So the only way I can really “fix” these issues is to document the input modes’ behavior and come up with a heuristic that please them all — but they are too alien for me to figure out how they are supposed to work without some help from users.
As for the rest of the system, my guess is that they (NSTextView) are handling this outside Cocoa (more low-level) because I pretty much has been through exactly the same with deciphering Cocoa key events and supporting different keymaps — here I also ended up with a heuristic I had to alter multiple times as I learned about new keymaps for which the old heuristic failed — even Apple was unable to provide me with code that could correctly handle the problem (I used a paid support incident).
OK, this was a bit of a rant… just so you guys know that lack of fully functioning CJK is by no means because I don’t think it’s important.
Hi Kevin,
I don't think that a text editor needs to handle various text formats or styles like a word processor, either. Of course, no one requires perfect input controls. However, I suppose it's a serious problem that a text editor can't handle a character input to a plain text correctly. This is such a basic problem. While writing source codes, it's few to enter CJK characters very much, but not 0. Only for the purpose end-users should use other tools...it is cart before the houses, isn't it?
The text editors which has little problems with character inputs in CJK languages are only BBEdit, SubEthaEdit and TextEdit.app, but I believe it's preferable that Textmates will join the group.
Best,
On 2011/12/15, at 19:29, Allan Odgaard wrote:
(snip)
-- Koichi MATSUMOTO - http://maccoterie.com/ contact me? please see http://mch.tel/ --
On 15 Dec 2011, at 18:58, Koichi MATSUMOTO wrote:
SEE and TextEdit both use NSTextView and BBEdit is not Cocoa.
What I was saying is that I am struggling with what seems to be oversights in the Cocoa API for doing this stuff, but I’m doing my best to make it work with what I have, and it’s really just a question of time because I need to collect empirical data to devise the proper heuristics.
Hi Allan,
Well, if what I said sounds like what I couldn't understand your efforts, I must say sorry. I know you are doing your best. However, in Japan, what we have few options is really bothering us. I sincerely wish you to understand me and figure this issue out.
On 2011/12/16, at 6:16, Allan Odgaard wrote:
(snip)
-- Koichi MATSUMOTO - http://maccoterie.com/ contact me? please see http://mch.tel/ --
-
Allan Odgaard -
Kevin Griffin -
Koichi MATSUMOTO -
Niels Kobschätzki