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.

Sign up for GitHub

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

Jump to bottom

Multiple compatibility issues with Google Japanese Input (IME) in vim with WSL #13681

Closed
Tracked by #6999
robqliu opened this issue Aug 5, 2022 · 14 comments
Closed
Tracked by #6999

Multiple compatibility issues with Google Japanese Input (IME) in vim with WSL #13681

robqliu opened this issue Aug 5, 2022 · 14 comments
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal.
Milestone
Backlog

Comments

@robqliu
Copy link

robqliu commented Aug 5, 2022 •
edited
Loading

Windows Terminal version

1.14.1962.0

Windows build number

10.0.19044.0

Other Software

$ vi --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)
Included patches: 1-2434
Extra patches: 8.2.3402, 8.2.3403, 8.2.3409, 8.2.3428

inside WSL (debian)

Steps to reproduce

  1. Install Google Japanese Input IME
  2. Open up vim within Terminal and launch a WSL session (I'm on debian, but I doubt it matters?)
  3. Hit alt + shift and then observe the issues described below.

Expected Behavior

Sorry for combining multiple issues into one ticket. I can split it up if it helps.

  1. The first issue is that the normal hotkey for swapping to japanese input is not swapping to the last used "mode". For instance, Google Japanese Input has multiple modes (Hiragana, Full-width Katakana, Full-width alphanumeric, etc.). What I've observed is that alt + shift swaps between your most recently used IMEs and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to Half-width alphanumeric. It's worth noting that this is true even when I'm not in vim/when I'm just on the command line in bash.
  2. Related to (1), if I use alt + ` , it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between Half-width alphanumeric and Direct Input.
  3. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. For instance, I often am in Hiragana mode when I'm typing (i.e. Insert Mode in vim). When I want to navigate text, I swap to Normal mode in vim and it magically swaps to Direct Input as is necessary for moving around. As you can see in the gif, it stays in Hiragana mode.

For what it's worth, (1) matters a lot less than (2) or (3) since I can stay with the Google Japanese Input IME for the most part without issue. In particular, once I swap to Hiragana manually (or via ctrl + caps lock) then (2) actually stops being an issue? Or at least it lets me cycle between Hiragana and Direct Input which is what I care about. (3) is super annoying because I basically have to train different muscle memory when I use Terminal vs gvim or even git bash for windows.

Actual Behavior

As described above, I would like the behavior here to match other apps:

  1. alt + shift into Google Japanese Input should pick the most recently used "mode" in that IME
  2. alt + ` should cycle through all of the modes
  3. It should swap between the most recently used mode (e.g. Hiragana) and Direct Input when going between Insert mode and Normal mode in vim

bug
@robqliu robqliu added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Aug 5, 2022
@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 Aug 5, 2022
@zadjii-msft
Copy link
Member

@lhecker another related to #13398. Wanna just take a quick sanity pass on this IME too?

@lhecker
Copy link
Member

lhecker commented Aug 5, 2022 •
edited
Loading

I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥
Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does.
Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior...

Edit (2022-08-15):
Sorry about my confusion in regards to Alt+Shift btw. I forgot that I disable it by default on my setups (so that it doesn't interfere with any shortcuts I configure - I use Win+Space instead which always works):
image

@ashemedai

This comment was marked as off-topic.

Sign in to view
@lhecker

This comment was marked as off-topic.

Sign in to view
@lhecker
Copy link
Member

lhecker commented Aug 5, 2022 •
edited
Loading

  1. Possibly related to the above issues, once I'm using Google Japanese Input, I expect it to swap between my usual mode, Hiragana, and Direct Input Mode when I swap modes in vim. [...]

@robqliu I'm not 100% certain I understood you correctly, but I believe we can't fix that issue (point 3.), because a Terminal has no knowledge about what "kind" of input an application wants. In other words, vim doesn't tell the terminal when it enters or exits edit mode, so we can't switch between Hiragana/Direct input mode either.
But maybe the this works in gvim (i.e. the UI version of vim for Windows), since that one isn't actually running in a terminal? gvim has full control over how it wants input, so they could definitely support that feature.

@ashemedai

This comment was marked as off-topic.

Sign in to view
@robqliu
Copy link
Author

robqliu commented Aug 5, 2022 •
edited
Loading

I've just installed the IME and I'm already hitting a problem at reproducing the issue. 😥 Alt+Shift doesn't switch between the most recently used mode for me. Alt+` does. Are you perhaps using any custom settings for Google Japanese Input or a different version? I'm on 2.28.4650.0. I couldn't find any setting that would change this behavior...

The alt+shift binding I learned when I was using the Microsoft Japanese IME. Here are some random links that mention it, I don't believe I ever manually added a binding (nor do I really see how...):
https://sethclydesdale.github.io/genki-study-resources/help/writing/#microsoft-shortcuts
https://answers.microsoft.com/en-us/windows/forum/all/japanese-ime-hiragana-toggle-keys/3b2ffa3e-29ee-4d5a-b65b-dc67c9c869fc

Yeah I've seen the point about gvim vs. vim in other tickets, but I think I'm just confused how git bash for windows seems to deal with this. It uses a specially compiled version of vim but shouldn't it have the same issues? Or do you think their vim is somehow integrated with the git bash terminal in a way that it can toggle the current IME? I can try swapping to gvim since I already have an x-server setup for other apps, but I've always had minor issues with gvim (probably just my configuration being not-actually-portable).

edit Hm, gvim seems to have other issues. I can swap to Hiragana via alt + ` , but it... doesn't actually work? Like I can't actually type hiragana/there's no pop-up window--it's identical to if the keyboard was still set to ENG. Also, it doesn't seem to swap IMEs based on input mode vs. normal mode. I wonder if this is just a configuration issue with gvim though...

@yuru7
Copy link

yuru7 commented Aug 7, 2022

I think alt+shift binding is a Windows settings.

The setting procedure is described in the following page. I apologize that it is in Japanese and is a help page of a computer manufacturer.
https://support.hp.com/jp-ja/document/c02652602

@driver1998
Copy link

driver1998 commented Aug 12, 2022 •
edited
Loading

Alt-Shift is a Windows shortcut to switch between input languages, not keyboard layouts or IMEs. So you'll need something like English language and Japanese Language with IMEs for it to work.

Ctrl-Shift is for switching keyboard layouts or IMEs within a language.

@zadjii-msft
Copy link
Member

zadjii-msft commented Aug 15, 2022 •
edited
Loading

Sorry, there's a lot to try and unpack here. To try and summarize:

  1. "alt+shift should swap between your most recently used IMEs, and it preserves the mode in Google Japanese Input for me... unless I'm using Terminal, in which case it seems to always go to Half-width alphanumeric"
  2. if I use alt + `, it normally cycles through all of the "modes". When I'm in Terminal, it seems to only cycle between Half-width alphanumeric and Direct Input
    • Same as above
  3. Yea, this sounds like something that gvim can do, but vim in the Terminal wouldn't be capable of (there's no way for a client app to tell it's connected terminal window to change the IME mode)

Right? Maybe we can get a hotfix build of 1.15 with that PR in it out soon to confirm?

@robqliu
Copy link
Author

robqliu commented Aug 15, 2022

Hm, the issues linked to in that commit seem orthogonal, but the description of the fix feels vaguely generic enough that it might end up fixing (1) and (2)? Looking forward to trying out a build when it's available

For (3), I think I'm just curious why "git bash for windows" seems to support this if WSL can't. Like how is their version of vim "tell[ing] the terminal when it enters or exits edit mode"? But yeah, if it's truly impossible then that's how it is. Though it's worth noting that gvim doesn't seem to work well in WSL per my comment above, but I can file a separate ticket for that

@rabianr rabianr mentioned this issue Aug 20, 2022
Closed
@zadjii-msft zadjii-msft mentioned this issue Aug 22, 2022
Closed
@zadjii-msft zadjii-msft mentioned this issue Nov 18, 2022
Closed
@PankajBhojwani PankajBhojwani added this to the Backlog milestone May 10, 2023
@PankajBhojwani PankajBhojwani added Area-Input Related to input processing (key presses, mouse, etc.) Product-Terminal The new Windows Terminal. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels May 10, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Tag-Fix Doesn't match tag requirements label May 10, 2023
This was referenced Jul 17, 2023
Open
Closed
@lhecker lhecker mentioned this issue Apr 16, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Apr 18, 2024
@lhecker
A minor TSF refactoring (#17067)
4e7b63c 
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 ✅
@lhecker
Copy link
Member

lhecker commented Apr 18, 2024

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 already have the Canary build installed, you can use this link to force an update.

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. 😊

@robqliu
Copy link
Author

robqliu commented Apr 19, 2024

The issue where I couldn't swap to "hiragana" was resolved months ago (I'm on 1.19.10302.0). That's like half of (2) in the original issue. But was also the most important thing I cared about. To be clear, these things still do not work, but I don't consider to be essential:

  1. alt + shift does not preserve the state of an IME. It always swaps to Direct Input for me in Terminal
  2. ``alt + ``` does not swap between all of the modes. It only swaps between Direct Input and Hiragana
    • I don't actually know how I was doing this before, but it appears to only swap between these two in all applications for me now.
  3. The IME mode does not automatically swap to Direct Input when I go to normal mode in vim. Similarly, it does not automatically swap to Hiragana mode when I go to insert mode

I don't remember which of these is supposedly possible or not for (vim on) Terminal to do, but just wanted to note that the most important part of this ticket is resolved for me.

@zadjii-msft zadjii-msft added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 3, 2024
@carlos-zamora
Copy link
Member

Thanks for working with us. The first one is fixed in 1.21 (at least as best as it can be). And the third one is inherently impossible. Closing as fixed 😊

@zadjii-msft zadjii-msft mentioned this issue Aug 29, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Product-Terminal The new Windows Terminal.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
8 participants
@ashemedai @robqliu @lhecker @carlos-zamora @yuru7 @zadjii-msft @driver1998 @PankajBhojwani