No fallback when using multiple keysyms per level

[wismill]

In order to support multiple keysyms per level, one has to use e.g. xkb_state_key_get_syms and not xkb_state_key_get_one_sym. From the doc of xkb_state_key_get_one_sym:

This function is similar to xkb_state_key_get_syms(), but intended for users which cannot or do not want to handle the case where multiple keysyms are returned (in which case this function is preferred).

But there are cases when we would like xkb_state_key_get_one_sym to return a fallback keysym:

1. The initial use case for multiple keysyms per level was to be able to type glyphs that requires multiple Unicode code points to be encoded. The issue is that such key:

• Provides no feedback to the user when an app uses only xkb_state_key_get_one_sym: it simply does nothing at all.
• Cannot be used in shortcuts, which usually require only one keysym.

2. key <LCTL> { [ { Control_L, ISO_Group_Shift } ] };: Here ISO_Group_Shift is a considered a side effect, but if multiple keysyms are not supported then we loose Control_L completely. It would be very useful to be able to fallback to a single keysym Control_L, e.g. when loading the keymap into XWayland. Else no interpretation is run on the key and it may affect virtual modifiers mappings to real modifiers.

Issue 1 can be solved using e.g. a Unicode keysym in Unicode PUA and a corresponding entry in a Compose file. However, there is no alternative for issue 2.

We cannot blindly fallback to the first keysym of a list, because it may not make sense. But what about proposing to specify the fallback explicitly? E.g. (note the |):

// Fallback to simply `Control_L` when using `xkb_state_key_get_one_sym` or similar functions.
key <LCTL> { [ { Control_L, ISO_Group_Shift } | Control_L ] };
// Different order, same result.
// It depends if we read the previous as “graceful degradation” or the next as “progressive enhancement”.
key <LCTL> { [ Control_L | { Control_L, ISO_Group_Shift } ] };
// Invalid: must be a single keysym and a single list
key <LCTL> { [ { Control_L, x } | { Control_L, ISO_Group_Shift } ] };
// Invalid: must be a single keysym and a single list
key <LCTL> { [ a | b | c ] };

// Some other ideas
// Better grouping?
key <LCTL> { [ { Control_L, ISO_Group_Shift | Control_L } ] };
// Better to be explicit but verbose?
key <LCTL> { [ { Control_L, ISO_Group_Shift, fallback=Control_L } ] };

What about the actions? I think we should run the interpretations on all keysyms, even if the resulting actions differ: we defer the decision whether it makes sense or no to the layout designer. Note that the action on the single keysym will be unused by the state; it would be used only in an hypothetical compatibility format for e.g. loading into X servers.