Compose sequences which require shift have stopped working since 1.6.0

[klausman]

OS is Debian trixie, with the (likely) relevant package being libxkbcommon0-1.5.0/1.6.0

I am using Wayland/labwc and configure my keyboard through these env vars:

XKB_DEFAULT_LAYOUT=us
XKB_DEFAULT_OPTIONS=compose:ralt,caps:none

Making CapsLock a noop works fine.

Since I updated the mentioned library to 1.6.0, compose-"-a does not result in ä but "a. Sequences that do not require shift for the first key work fine (e.g. c-/-o gives ø). Similar, making capital letters like the uppercase variant of ø doesn't work: I just get O. It seems like using the shift key at all immediately cancels the compose sequence.

I am unsure what happened here, since my above configuration is just reusing existing xkb configuration setups. Due to this being Wayland, xmodmap and the like are not used at all.

I wanted to try and downgrade the Debian package, but ran into all manners of dependency problems and didn't want to break my main system, so I couldn't try 1.5.0 to make sure things are fine with that version.

[wismill]

I cannot reproduce this under KDE Wayland.

• In what apps did you try? Does it fail with Gtk-based apps (e.g. Firefox) as well as Qt-based ones (e.g. KDE apps)?
• Do you happen to use a custom Compose file?

• Could you try to use the following minimal Compose file:

  # NOTE: Do not import any system file
  <Multi_key> <quotedbl> <q>        : "x"   x
  

  Save this file as ~/.XCompose and restart your session, then try to type Compose + " + q. Do you see x?

• Remove the previous ~/.XCompose file.
• Install xkbcommon-tools, execute

  xkbcli interactive-evdev --enable-compose --layout us --options compose:ralt,caps:none

  in a terminal, then type the Compose sequences and copy back the output here. Note that you may need to add your user to the input group.

[klausman]

In what apps did you try? Does it fail with Gtk-based apps (e.g. Firefox) as well as Qt-based ones (e.g. KDE apps)?

Compose does not work in foot, but it seems to work in Firefox (running as a Wayland client).

Do you happen to use a custom Compose file?

No, all XKB stuff I do is the two mentioned environment variables

Could you try to use the following minimal Compose file:

# NOTE: Do not import any system file
<Multi_key> <quotedbl> <q>        : "x"   x

Save this file as ~/.XCompose and restart your session, then try to type Compose + " + q. Do you see x?

This still gives me the output "q

• Remove the previous ~/.XCompose file.
• Install xkbcommon-tools, execute

  xkbcli interactive-evdev --enable-compose --layout us --options compose:ralt,caps:none

  in a terminal, then type the Compose sequences and copy back the output here. Note that you may need to add your user to the input group.

$ xkbcli interactive-evdev --enable-compose --layout us --options compose:ralt,caps:none
keycode [ AC01 ] keysyms [ adiaeresis       ] unicode [ ä ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] 

If I type the same sequence into another foot window while xkbcli is running, the result there is still "a, while xkbcli shows the same (correct?) output as above.

[wismill]

Compose does not work in foot, but it seems to work in Firefox (running as a Wayland client).

Do you mean this foot?

This still gives me the output "q

It seems your application is not implementing Compose correctly. Since Gtk-based application works, could you try a Qt-based application?

$ xkbcli interactive-evdev --enable-compose --layout us --options compose:ralt,caps:none
keycode [ AC01 ] keysyms [ adiaeresis       ] unicode [ ä ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] 

If I type the same sequence into another foot window while xkbcli is running, the result there is still "a, while xkbcli shows the same (correct?) output as above.

See my previous answer. It sounds like a foot issue.

[klausman]

Compose does not work in foot, but it seems to work in Firefox (running as a Wayland client).

Do you mean this foot?

I think the canonical place is https://codeberg.org/dnkl/foot, but yes.

This still gives me the output "q

It seems your application is not implementing Compose correctly. Since Gtk-based application works, could you try a Qt-based application?

It also works in Qt apps (e.g. qpwgraph or qlvc). I also tried xterm (running in xwayland mode, of course), and compose works correctly there as well. So suspecting foot being the problem, I built and compiled v1.15.3 (current would be 1.16.x), but it still showed the incorrect behavior.

$ xkbcli interactive-evdev --enable-compose --layout us --options compose:ralt,caps:none
keycode [ AC01 ] keysyms [ adiaeresis       ] unicode [ ä ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] 

If I type the same sequence into another foot window while xkbcli is running, the result there is still "a, while xkbcli shows the same (correct?) output as above.

See my previous answer. It sounds like a foot issue.

I think you're right (despite foot 1.15.3 also showing the bad behavior), so I'll report it there. If-when I get a solution there, I will report back here (feel free to close this issue or leave it open, whatever best suits your workflows).

[wismill]

I think the canonical place is https://codeberg.org/dnkl/foot, but yes.

I realized that, but you were too quick 😄

Thanks for your quick feedback. You can point our implementation in the interactive tool to help the devs.

Feel free to reopen if you have news.

[klausman]

Since nobody but me seemed to be able to repro this, I did a fresh checkout of master (0bd265600edc165b2a763c35c2e148ba93705b5d) and recompiled, and voilá, compose works correctly again.

Sorry for the noise!

[wismill]

Good to know it works again.

Sorry for the noise!

Please do not and continue to report bugs!