Determine whether an input method has uncommitted ("marked") text when p...

[JimLiu]

...ress enter

If user is typing with an non-english input method, do not send message out when he press enter.

[iceboundrock]

Cool, definitely fixed my problem :)

[nickcheng]

Cool! It helps a lot.

[JimLiu]

hm, you changed only one line, and don't added new variable 'hasMarkedText'? Where is full commit?

Yes, this is the full commit!

At first, let reproduce this bug:

1. Switch IME to a Chinese or Japanese input method like Pinyin - Simplified
2. Typing some word like nihao, then marked text appears
   
3. Meanwhile if user press Enter, it's NOT supposed to send the message

So I added a line self.hasMarkedText to check if it has marked text to select.

Reference: Cocoa Text Architecture Guide - Text Editing - Creating a Custom Text View - Managing Marked Text

[overtake]

thanks, i got it

[JimLiu]

@overtake It seemed that this commit had not been merged? This bug has still not been fixed in the new version.

[nicekei]

@JimLiu Hi, after applying your patch, we are having problems sending messages - we need to enter double times to send a message. Korean users are complaining about it(https://itunes.apple.com/kr/app/telegram/id747648890?mt=12). See also #62.

[JimLiu]

@nicekei I'll take a look later. If the issue can be reproduced, it can be fixed.

[nicekei]

@JimLiu eg. Type "gkgk" with the Korean input method which result in "하하", then press enter. The message would not be sent.

The thing is that, the marked text itself is not sufficient to check if the enter key be regarded as the send key OR the IME composition related key. In Korean case, although you can see the underlined/marked text in the text view, there's no other candidates and its just simple text which is ready to be sent.

I think the current Telegram message sending way causes this problem.
It directly checks if the users pressed the enter key, but it doesn't know if the candidate windows were shown - so it can not decide to send the message or not.
But NSTextView knows it. It changes the text based on the user input AND IME. If users used the send enter key, the resulting text would contain another "\n". Because the telegram is using NSTextView not the keyboard input directly, the better approach would be checking the resulting text from NSTextView, and then decide to send the message or not.
ie. To send a message or not should be based on the resulting text's "\n" changes, not based on the user pressed enter key. I think @overtake can comment his ideas about it. Thanks
(Note that there are few more cases to handle carefully. eg. Copy/Paste, Command+Enter. )

[nicekei]

@JimLiu Any progresses? Its been a while since I last reported this one. Korean people loves telegram - but I feel sorry about the situation that Mac users are continuously complaining about the issue I mentioned. How about rollback your commit? At least you can add an option for this mod. eg. "Do not send the marked text". Your committed codes result in the disaster - it work in your cases. but its disaster in other cases. Simply speaking, that didn't work. I don't know why @overtake isn''t commenting anything about it. Is telegram for Mac dead?

[overtake]

@nicekei for others people this code is bad, because need press enter two times. i don't understand this issue ;(

[nicekei]

@overtake I'm glad you are back. Entering two times is annoying, seriously. This code snippet was incomplete/wrong, but got into the actual release. What should we do?

[iceboundrock]

@nicekei this is an open source project, @JimLiu send a PR and his PR did fix an issue for people who using Chinese input method. If you have a better idea, please send your PR.

[nicekei]

@iceboundrock Sure its an open source project. What @JimLiu made is a PR which fixes an issue in some cases but produces an annoying error in other cases. Note that we are sharing the same code base - telegram is an international messenger NOT a Chinese only messenger . If there were some tests to check, this PR wouldn't pass it I think. I'm pointing out that this PR was not accurate. Imagine that if I made a PR which fixes issues in Korean, but produces some bugs in others. In that case, that PR should not get into the master branch. But this was not the case here. The breaking PR got into the master branch.

Maybe I could check it all myself and made a fix. But we can talk before code :) @JimLiu made the PR and I found this bug reported it to him, and he said he will look into it. Maybe I was waiting for some response.

Anyway I'd like to fix this problem too. If he couldn't fix the bug, I will dig into this problem and make some fixes to this issue :D