Plover doesn’t output accented letters correctly, among other characters on the third level

[casperdewith]

description

Some characters are on the third or fourth level of a keyboard layout. If a dictionary entry contains such a character, and you stroke its outline, then Plover doesn’t input this character correctly.

to reproduce this behaviour

1. Use a keyboard layout with characters on the third level, e.g. the US-international keyboard layout.
   • This means that such characters can only be input while holding the third-level key; usually AltGr.
2. Stroke SA/SRA in a text field. In main.json, this maps to ça va.

expected output – ça va
actual output – ,a va

For context, on the US-international keyboard, the ç key can (only) be input with the combination AltGr+,. Hence, I think that Plover can find the right key to press, but cannot figure out how to deal with the third level and AltGr.

operating system

• Ubuntu 22.04 LTS on Wayland
• Plover 4.0.0.dev12

hardware

The Polyglot keyboard, with standard settings as described in this documentation.

[user202729]

Things you can try to do:

• exit Plover, setxkbmap us -variant intl, reopen Plover
• run xev, and read the log on what happens when you use Plover to type the ç, and what happens when you use AltGr+, to type the ç.
• run xmodmap -pke and xmodmap -pm and paste the result here.

---

Some notes

• setxkbmap us -variant intl to switch to the layout
• relevant part of xmodmap -pke is keycode 59 = comma less comma less ccedilla Ccedilla ccedilla. You can run xmodmap -e 'keycode ...' to set only that key.
• (because of some issues Update keymap on keymap change #1164 , to be careful remember to exit Plover, modify key map, then re-open Plover)

Worth noting the code did take this into account

                if 4 <= keysym_index <= 5:
                    # 3rd (AltGr) level.
                    modifiers |= X.Mod5Mask

I cannot confirm the issue trying to do the above.

Another thing worth checking is whether the last entry is empty

In [17]: engine._keyboard_emulation.modifier_mapping
Out[17]: 
[array('B', [50, 62, 0, 0]),
 array('B', [66, 0, 0, 0]),
 array('B', [37, 105, 0, 0]),
 array('B', [64, 108, 204, 205]),
 array('B', [77, 0, 0, 0]),
 array('B', [203, 0, 0, 0]),
 array('B', [133, 134, 206, 207]),
 array('B', [92, 0, 0, 0])]

---

xinput type <string> works correctly. Checking with xev shows it does not send a keydown-keyup for the AltGr itself. With some testing I can confirm it's because of the line

    XkbLockGroup(xdo->xdpy, XkbUseCoreKbd, key->group);

where setting the group to 2 makes pressing , output ç.

If I recalled correctly python-xlib does not support Xkb though.

[seangenabe]

Based on my (limited) knowledge of keyboard emulation, implementation of Unicode input would be dependent on the operating system. Ref: https://github.com/qmk/qmk_firmware/blob/master/docs/feature_unicode.md#2-input-modes-idinput-modes

Don't know if this is going to be relevant though.

[Monniasza]

I get "cava" instead.