RMLVO model symbols only inherited by first layout

[afrantzis]

Background

The pc(pc105) symbols define key <LSGT> { [ less, greater, bar, brokenbar ] };.
The us(colemak) symbols define key <LSGT> { [ minus, underscore, endash, emdash ] };
The us(basic) symbols do not define <LSGT>

A two group us, us(colemak) configuration works as expected with Group1 inheriting the <LSGT> symbols from pc(pc105), whereas Group2 (colemak) using its own symbols:

$ setxkbmap us,us ,colemak -print | xkbcomp -xkb - - 2>/dev/null | grep -A4 'key <LSGT>'
    key <LSGT> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [            less,         greater,             bar,       brokenbar ],
        symbols[Group2]= [           minus,      underscore,          endash,          emdash ]
    }

The problem

However, the two group configuration in the opposite order us(colemak), us doesn't have Group2 at all:

$ setxkbmap us,us colemak, -print | xkbcomp -xkb - - 2>/dev/null | grep -A4 'key <LSGT>'
    key <LSGT> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [           minus,      underscore,          endash,          emdash ]
    };
    key <FK11> {

I would expect for Group2 to exist with the value inherited from pc105, like in the previous case.

Notes

The symbols combination for the problematic configuration is:

xkb_symbols { include "pc+us(colemak)+us:2+inet(evdev)+group(alt_shift_toggle)" };

Using the pc symbols for both groups explicitly allows 'Group2' to properly inherit the symbols:

$ setxkbmap -symbols 'pc+pc:2+us(colemak)+us:2' -print | xkbcomp -xkb - - 2>/dev/null | grep -A4 'key <LSGT>'
    key <LSGT> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [           minus,      underscore,          endash,          emdash ],
        symbols[Group2]= [            less,         greater,             bar,       brokenbar ]
    };

I am trying to understand the situation, and it seems one of the following is true:

1. My expectation and understanding is incorrect and the current behavior is correct (hopefully not!).
2. The translation from RMLVO to symbol combination is incorrect, and should include the model symbols for all groups, like in the example above, or something along that lines.
3. The translation from RMLVO to symbol combination is correct (i.e., single model symbols at start of combination), but the interpretation of this combination is incorrect.

Thoughts?

Thanks!

[afrantzis]

Here is a minimal test case for the us/us(colemak) scenarios mentioned in the description:

diff --git a/test/rulescomp.c b/test/rulescomp.c
index eddf306..106da8c 100644
--- a/test/rulescomp.c
+++ b/test/rulescomp.c
@@ -156,6 +156,22 @@ main(int argc, char *argv[])
                       KEY_LEFTALT,    UP,   XKB_KEY_Alt_L,                NEXT,
                       KEY_APOSTROPHE, BOTH, XKB_KEY_dead_grave,           FINISH));
 
+    assert(test_rmlvo(ctx, "evdev", "pc105", "us,us", ",colemak", "grp:alts_toggle",
+                      KEY_102ND,      BOTH, XKB_KEY_less,                 NEXT,
+                      KEY_LEFTALT,    DOWN, XKB_KEY_Alt_L,                NEXT,
+                      KEY_RIGHTALT,   DOWN, XKB_KEY_ISO_Next_Group,       NEXT,
+                      KEY_RIGHTALT,   UP,   XKB_KEY_ISO_Level3_Shift,     NEXT,
+                      KEY_LEFTALT,    UP,   XKB_KEY_Alt_L,                NEXT,
+                      KEY_102ND,      BOTH, XKB_KEY_minus,                FINISH));
+
+    assert(test_rmlvo(ctx, "evdev", "pc105", "us,us", "colemak,", "grp:alts_toggle",
+                      KEY_102ND,      BOTH, XKB_KEY_minus,                NEXT,
+                      KEY_LEFTALT,    DOWN, XKB_KEY_Alt_L,                NEXT,
+                      KEY_RIGHTALT,   DOWN, XKB_KEY_ISO_Next_Group,       NEXT,
+                      KEY_RIGHTALT,   UP,   XKB_KEY_ISO_Level3_Shift,     NEXT,
+                      KEY_LEFTALT,    UP,   XKB_KEY_Alt_L,                NEXT,
+                      KEY_102ND,      BOTH, XKB_KEY_less,                 FINISH));
+
     assert(test_rmlvo(ctx, "", "", "", "", "",
                       KEY_A,          BOTH, XKB_KEY_a,                    FINISH));
 

[bam80]

Please see if it's somehow related: #262

[wismill]

This is a known issue in xkeyboard-config. See the corresponding ticket.

See also: #362