-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
IME still has some issues #13805
Comments
Thank you for creating a new issue for this. I thought it's related to the original issue so I didn't create a new one. I just checked the discussion at #12731. If I understand correctly, the intention of the patch is to switch IME input mode to Direct Input when user opens a new Terminal. Here is the demo with v1.13.10983.0 I wonder if this behavior is different with other MS IME? |
For reference: we've now been monkey-patching our IME support for... probably too long. We're gonna follow up with some folks more directly involved with the IME implementation, and seek out a more holistic design here. They'll likely have a set of best practices we should actually follow that'll work across different languages and IMEs. Hopefully, we can stop trying to whack-a-mole these issues. |
For a short-term solution, having a option to turn off IME related things might be enough. |
I think it's best to address this issue together with #14349, by unifying our two IME implementations. |
I'm using Microsoft Chinese IME with Windows Terminal 1.17.11461.0. |
Next in the popular series of minor refactorings: Out with the old, in with the new! This PR removes all of the existing TSF code, both for conhost and Windows Terminal. conhost's TSF implementation was awful: It allocated an entire text buffer _per line_ of input. Additionally, its implementation spanned a whopping 40 files and almost 5000 lines of code. Windows Terminal's implementation was absolutely fine in comparison, but it was user unfriendly due to two reasons: Its usage of the `CoreTextServices` WinRT API indirectly meant that it used a non-transitory TSF document, which is not the right choice for a terminal. A `TF_SS_TRANSITORY` document (-context) indicates to TSF that it cannot undo a previously completed composition which is exactly what we need: Once composition has completed we send the result to the shell and we cannot undo this later on. The WinRT API does not allow us to use `TF_SS_TRANSITORY` and so it's unsuitable for our application. Additionally, the implementation used XAML to render the composition instead of being part of our text renderer, which resulted in the text looking weird and hard to read. The new implementation spans just 8 files and is ~1000 lines which should make it significantly easier to maintain. The architecture is not particularly great, but it's certainly better than what we had. The implementation is almost entirely identical between both conhost and Windows Terminal and thus they both also behave identical. It fixes an uncountable number of subtle bugs in the conhost TSF implementation, as it failed to check for status codes after calls. It also adds several new features, like support for wavy underlines (as used by the Japanese IME), dashed underlines (the default for various languages now, like Vietnamese), colored underlines, colored foreground/background controlled by the IME, and more! I have tried to replicate the following issues and have a high confidence that they're resolved now: Closes #1304 Closes #3730 Closes #4052 Closes #5007 (as it is not applicable anymore) Closes #5110 Closes #6186 Closes #6192 Closes #13805 Closes #14349 Closes #14407 Closes #16180 For the following issues I'm not entirely sure if it'll fix it, but I suspect it's somewhat likely: #13681 #16305 #16817 Lastly, there's one remaining bug that I don't know how to resolve. However, that issue also plagues conhost and Windows Terminal right now, so it's at least not a regression: * Press Win+. (emoji picker) and close it * Move the window around * Press Win+. This will open the emoji picker at the old window location. It also occurs when the cursor moves within the window. While this is super annoying, I could not find a way to fix it. ## Validation Steps Performed * See the above closed issues * Use Vietnamese Telex and type "xin choaf" Results in "xin chào" ✅ * Use the MS Japanese IME and press Alt+` Toggles between the last 2 modes ✅ * Use the MS Japanese IME, type "kyouhaishaheiku", and press Space * The text is converted, underlined and the first part is doubly underlined ✅ * Left/Right moves between the 3 segments ✅ * Home/End moves between start/end ✅ * Esc puts a wavy line under the current segment ✅ * Use the Korean IME, type "gksgks" This results in "한한" ✅ * Use the Korean IME, type "gks", and press Right Ctrl Opens a popup which allows you to navigate with Arrow/Tab keys ✅
We just published a major update to our IME implementation in the nightly Canary branch. It was rewritten from the ground up and has tons of improvements! If you're interested in trying it out, you can get it here: https://aka.ms/terminal-canary-installer If you encounter any issues or have any suggestions, or if you simply like/dislike the changes, please let us know! Thank you for bearing with us. 😊 |
I'm sorry for bringing this up again.
Thanks to the commit #13678, the original issue is fixed in the latest version.
But recently, I've found that the new behavior is not very desirable. At least for me.
For example, when I'm in the middle of editing something in Hiragara mode then switch to a different application or make the Terminal lose focus. Then when the Terminal get focus again, the IME's input mode will be switched to Half-width alphanumeric.
It's not a bug, but kind of inconvenience. So may I request a setting to disable the new behavior?
v1.13.10983.0
v1.15.2282.0
I don't have other CJK languages installed, so it might happen with the Japanese MS IME only.
Also, I believe that the new behavior is causing
alt + shift
to not retaining the last used input mode as mentioned in #13681.v1.13.10983.0
v1.15.2282.0
Originally posted by @rabianr in #13398 (comment)
The text was updated successfully, but these errors were encountered: