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.