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

When entering a Chinese punctuation, it acts like keeping hitting the key #3706

Closed
wrvsrx opened this issue Nov 26, 2019 · 7 comments · Fixed by #4140
Closed

When entering a Chinese punctuation, it acts like keeping hitting the key #3706

wrvsrx opened this issue Nov 26, 2019 · 7 comments · Fixed by #4140
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@wrvsrx
Copy link

wrvsrx commented Nov 26, 2019

Environment

Windows build number: 10.0.19030.1
Windows Terminal version: 0.7.3291.0

Steps to reproduce

Hit the key "," (or other punctuation) in windows terminal with Chinese input method

Expected behavior

Output a "," (I delete the extra "," in the following picture manually)

image

Actual behavior

keeps outputting "," just like I keep hitting the ","

image

Some other information

  1. I have reproduced it in Windows Terminal using wsl, cmd and powershell7-preview on my two PCs.
  2. Another phenomenon is that Windows Terminal add space behind Chinese character automatically after my inputting one character.
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 26, 2019
@etern
Copy link

etern commented Nov 27, 2019

For me, I have to type twice to input one Chinese puncutation, like period(。), I'm also using terminal version 0.7.3291.0

It reminds me this issue #2191 , one Chinese character rendered as two small charactors.
It seems wide character is not handled properly.

@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. labels Nov 27, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 27, 2019
@zadjii-msft zadjii-msft added this to the Terminal v1.0 milestone Nov 27, 2019
@DHowett-MSFT DHowett-MSFT added Help Wanted We encourage anyone to jump in on these. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Dec 2, 2019
@ice1000
Copy link

ice1000 commented Dec 13, 2019

I am in the same situation as @etern 's instead of OP's

@Lemmingh
Copy link

Lemmingh commented Dec 16, 2019

I have the same problem as @etern which has been discussed in #3745

Though looking opposite, I wonder whether these issues are related in some aspect.


Windows build number: 10.0.18363.535
Windows Terminal version : 0.7.3451.0

@luxrck
Copy link

luxrck commented Dec 17, 2019

I have encountered the same bug @wrvsrx

image

wt version: 0.7.3382.0

@wrvsrx
Copy link
Author

wrvsrx commented Dec 17, 2019

Recently, I test it on another PC whose windows build number is 10.0.18363.535, and it behave like what #3745 describes. Comparing this to windows terminal's behavior mentioned above on my PC with windows build number 10.0.19030.1, I think it might be related to the windows version.

@luxrck
Copy link

luxrck commented Dec 17, 2019

@wrvsrx And my windows version is: 10.0.19037.1
Seems that it did relate to the win10 version......

@ghost ghost added the In-PR This issue has a related PR label Jan 8, 2020
@ghost ghost closed this as completed in #4140 Jan 8, 2020
ghost pushed a commit that referenced this issue Jan 8, 2020
The first argument to `NotifyTextChanged` incorrectly was `[0,0]`
instead of the length of the text to be removed from the
`CoreTextEditContext`.

Best source of documentation for `NotifyTextChanged`:
https://docs.microsoft.com/en-us/windows/uwp/design/input/custom-text-input#overriding-text-updates

FYI @DHowett-MSFT (just in case): C++/WinRT uses `winrt::param::hstring`
for string parameters which intelligently borrows strings. As such you
can simply pass a `std::wstring` to most WinRT methods without the need
of having to allocate an intermediate `hstring`. 🙂

## Validation Steps Performed

I followed the reproduction instructions of #3706 and #3745 and ensured
the issue doesn't happen anymore.

Closes #3645
Closes #3706
Closes #3745
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jan 8, 2020
@ghost
Copy link

ghost commented Jan 14, 2020

🎉This issue was addressed in #4140, which has now been successfully released as Windows Terminal Preview v0.8.10091.0.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants