Cannot input japanese characters

[gullevek]

Which operating system does the issue occur on?

macOS 10.12.6

The Kana key to switch to japanese input is not registered, it only prints out a space. Same for the other key called Eiso.

Switching to japanese input manually via the menu bar does not work either

[francesca64]

Does this still happen on the latest version of Alacritty?

[AdrienLemaire]

@francesca64 happens for me on Arch Linux and alacritty-git 0.1.0.794.g96b3d73-1

My setup works for every application in my system (including previously used Termite terminal) except for alacritty.

$ pacman -Qs (anthy|uim|mozc)
local/anthy 9100h-5
    Hiragana text to Kana Kanji mixed text Japanese input method
local/mozc 2.23.2815.102-2 (mozc-im)
    A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source
    Edition of Google Japanese Input)
local/uim 1.8.8-3
    Multilingual input method library

$ head -n18 ~/.xinitrc |tail -n5 
export GTK_IM_MODULE='uim'
export QT_IM_MODULE='xim'
uim-xim &
export XMODIFIERS='@im=uim'
export QT_STYLE_OVERRIDE='GTK+'

When I press Ctrl-Space, nothing happens.
I have no idea what to debug in order to figure out this issue. Any help will be much appreciated :)

[andrewzah]

I get the same issue on Arch Linux with trying to switch to Hangul input. Also running Arch with the latest alacritty compiled from source.

[crocket]

I use fcitx on Gentoo Linux. I don't have this issue.

~/.xsession

export XMODIFIERS=@im=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export QT5_IM_MODULE=fcitx
export QT_QPA_PLATFORMTHEME=qt5ct

fcitx -dr

The fact that alacritty doesn't support inline japanese input is disappointing a bit because termite does.

[AdrienLemaire]

I was really looking forward to using alacritty, but no japanese input is a deal-breaker. Uninstalling it now, but would love to stay in touch with Alacritty's roadmap for the time when it'll be supported and I can jump onboard @jwilm

[h-michael]

I use Alacritty on Arch linux with fcitx and macOS 10.13.6.
I don't have this issue now.

[sawadashota]

I use Alacritty on macOS 10.14.2.
I can type Japanese and see it as result, but I cannot see it before conversion.

screenshot of Alacritty

screenshot of iTerm

[Spirarel]

I'm having the same problem as sawadashota. Same OS as well

[KeenS]

I have too, on Ubuntu. I'm using mozc as Input method.

[forestsource]

I have same problem.
Alacritty: 0.2.9, OSX 10.14.3, Japanese input(Google input).

[MatsLanGoH]

Can confirm the same problem - Japanese text is only rendered after completing conversion inside the IME window.
I've only begun learning Rust, but would like to help figuring out a solution if possible.

Alacritty: 0.2.9, macOS 10.14.4, System IME

[tyru]

I can't input any characters, but Kana key works so I can switch to japanese input method but I cannot input any japanese characters (typing aaaaaaaaa<Enter>. enter should insert preediting string to application textarea).

Enviroinment

• Japanese input method which is installed by default
  • some screenshots in macOS here appear using Google Input Method such as @sawadashota's comment but I'm default input method user (I don't know if this is specific problem to default input method though)
• alacritty 0.3.3 (brew cask ls --versions alacritty)
• macOS 10.14.6

ref. #1606 (comment)

[AdrienLemaire]

Finally found a solution to input japanese in Alacritty within wayland with ibus+mozc:

$ env WINIT_UNIX_BACKEND=x11 alacritty

related issue.
Hence my problem isn't with alacritty or sway, but with mozc not supporting wayland.

[kchibisov]

FWIW @AdrienLemaire your issue is tracked there #2734

[pickfire]

Is this still an issue japanese input with fcitx seemed to work for me on arch linux X11 on alacritty 0.4.2? I also tested with chinese input and it worked fine too.

[kchibisov]

Yeah, it's an issue, as you can the label is on macOS, however you're on X11 + linux, which should work.

[gandalf3]

For me "in-place input" isn't working in Linux/X11/ibus either, though it works in termite, as described by crocket above: #1101 (comment). The characters show up in a separate window created by the IME and only appear in alacritty once you confirm in the IME. Not the worst issue, but it'd be nice to see support for in-place editing.

[garasubo]

"in-place input" won't work since glutin library itself doesn't send pre-edit string information to the application.
There is a tracking issue for it in winit: rust-windowing/winit#1497

[garasubo]

#1613 may be the better place to discuss "in-place input" problem?

[ghost]

Well, I also have this issue, with fcitx, unicode input. Alacritty does not allow fcitx input?

[crocket]

Alacritty allows fcitx with x11 backend.

[komi1230]

This issue has been resolved in rust-windowing/winit#1979.
Wait for a moment to release new version of Winit and Glutin.

[fgsch]

This is great! Just tried master with Japanese and works as expected 🎉

[crocket]

How can I make fcitx work on alacritty wayland backend?

[fgsch]

I just tested 0.10.0-rc4 (6549303) and is no longer working :(

[fgsch]

It looks like the change that fixed this issue was reverted in winit (rust-windowing/winit@6b250a7).

[komi1230]

That change was just a hacky way to make Japanese input work fine. But Chinese input got awful by this change and it was decided to add some new API to make IME work fine in all languages.

I submitted another PR in rust-windowing/winit#2147 for this issue.

Sorry for inconvenience and wait for a while.

[fgsch]

@komi1230 No worries. Thank you for your on this. Hopefully we will have proper IME support soon!

[chrisduerr]

Thanks for your work @komi1230. Hopefully this can be properly resolved with the release after 0.10.0. For 0.10.0 the primary focus of course is not introducing any new regressions, so we'll have to wait until a proper fix is available.

[fgsch]

Hi. Is there anything else that needs to be done here now that rust-windowing/winit#2147 was merged?

[kchibisov]

A new winit release.

[adwinying]

Seems like winit released a new version couple days ago, could we expect an update with the new winit release anytime soon? 🤞

[adwinying]

This issue seems to be resolved in the latest release!

Screen.Recording.2022-10-13.at.15.51.47.mov