Compose key unresponsive after winint merge

[alerque]

As of now the merge of new winint stuff has fixed the keyboard layout issues for me, so #445 is fixed for me (Linux/Wayland).

On the other hand a new issue has cropped up: my Compose key doesn't do anything useful. This should be part of the system input framework, not individual app configs bug somehow the keys are being intercepted. Normally in almost any app I can tap the Compose key and then a sequence of characters and the app will just get the composed character, whatever that is. In the case of Neovide HEAD right now the last character of the compose sequence is inserted instead.

[fredizzimo]

We probably need to handle the compose event https://github.com/rust-windowing/winit/blob/6300cf915e21089481398c96cc38808764de0a9c/src/keyboard.rs#L857

[fredizzimo]

This should be fixed by #1899, it would be great if you can test that.

[alerque]

I'll give it a shot, but that's a little tricky when I'm also pretty dependent on PR #1870 as the only version that works for me in actual use ;-) And the two PRs have merge conflicts so I can't easily run both.

[fredizzimo]

Strange that #1870 is the only working version. It's not supposed to fix any known issues, other than perhaps this #1789 (comment). But the better fix for that is to run Neovide in real Wayland mode without WINIT_UNIX_BACKEND=x11. Or do you have some other issues it fixes? In that case we should probably speed up the process of getting it merged.

[alerque]

It is not that the others don't work is is that they are absolutely unusable slow (400-2000ms lag on key input) for me. Using --novsync makes it so that I can blunder through using them, probably 200-800ms lag, but nowhere even close to the snappy response of the smooth-render-loop PR.

[alerque]

No, building PR #1899 does not fix compose key sequences in Wayland for me.

[fredizzimo]

For the input lag, it's a bit strange, but I think I know what's going on. The old event loop did not handle all the pending events in the system event queue, before rendering. So if the rendering is too slow, the queue will fill up causing lag. I think you should be able to work around that by setting g:neovide_refresh_rate to something like slower, like 30.

And it's strange that it does not solve the compose. It seems to solve everything else, including IME. Does it work with the alacritty that also uses winit master https://github.com/kchibisov/alacritty/tree/winit-update?

[alerque]

No, I just built Alacritty from alacritty/alacritty#6958 (0.13.0.2131.gc1172a76) and compose sequences do not work their either. They do currently work in Gnome apps like Gedit, Firefox, and others. It even works in the NeoVIM instance I'm writing this comment in via Firenvim.

[fredizzimo]

I wonder if you need to do something like this (but probably not exactly that) https://www.csslayer.info/wordpress/linux/use-plasma-5-24-to-type-in-alacritty-or-any-other-text-input-v3-client-with-fcitx-5-on-wayland/. I had to do that to get IME with fcitx to work.

[fredizzimo]

Could you post your full system specification, so that we can open an issue on the Winit repository?

Linux distribution, desktop environment / windows manager any software you use for the compose key.

[alerque]

Arch Linux
Hyprland

Compose key is setup via Wayland kb, much like X11 has xkb options. My keyboard config is here:
https://github.com/alerque/que-wayland/blob/master/.config/hypr/hyprland.conf#L42-L46

[MultisampledNight]

@alerque TL;DR Could you test again, both #1899 and #1870, and share the results (ideally with exact commits)?

I tried both Sway and Hyprland (but with compose:rctrl since none of my keyboards have a menu key), and sequences like Compose + - + - + - → — or Compose + ~ + n → ñ worked just fine there. Only other significant difference in configuration is that I use Bone and am on NixOS, not Arch. Both PRs have seen quite a bit of movement lately, so it'd be cool to have differences in Neovide itself ruled out.

[alerque]

• Using Smooth render loop #1870 (0.10.4.r49.g56e27b7), compose key does not work. Initial impression is the speed seems to be okay still on this branch.
• Using fix: Simplify the use of the new winit keyboard API #1899 (0.10.4.r34.g1605826), compose key does not work. Responsiveness is so bad as to be unusable.

[alerque]

Just as a point of reference, Alacritty 0.12.2 just dropped, and the Compose key still doesn't work there either. It does almost everywhere else on my Wayland desktop (including this Firenvim session in Firefox).

[alerque]

Major new info! This has to do with locales. After this comment from an Alactritty dev I checked Neovide too, and LC_ALL=en_US.UTF-8 neovide using #1870 does in fact bring Compose key functionality!

The next problem is why LC_ALL is being used but all the other LC_* and LANG are being ignored.

[alerque]

At least in my case, this entire snafu was caused by inconsistent capitalization of the locale code. Setting LC_ALL as an override worked because it fixed my capitalization from the system locale. Using the canonical capitalization for language (lower), region (upper), and encoding (upper) (e.g. en_US.UTF-8) makes this whole problem go away and Compose works in both Alacritty and Neovide.

Sorry for the goose chase!

[MultisampledNight]

No worries, at least now it's on the web for somebody else to find! I'll add this to the FAQ on the website.