2a2a8d7 introduced the handling of Caps and Control keysyms transformations.

However, it works only for xkb_state_key_get_one_sym, but not for xkb_state_key_get_syms:

Also, only xkb_state_key_get_one_sym() is changed;
xkb_state_key_get_syms() is left as-is, and always reports the
untransformed keysyms.

I would like to revisit this decision:

This is for the following reasons:

• The API doesn't allow it, since we return a const pointer directly to
  the keymap keysyms table and we can't transform that.

We could use an internal buffer, such as for the Compose iterator (see xkb_compose_table_iterator::entry). As we discussed in #300, xkb_state is not meant to be thread-safe.

• The transformation doesn't make sense for multiple-keysyms.

I disagree: it feels quite a counter-intuitive result.

• It can be useful for an application to get the "raw" keysyms if it
  wants to (e.g. maybe it wants to do the transformation itself).

This is a valid point. But note that they are always available with xkb_keymap_key_get_syms_by_level.

Some directions:

1. Change the current API to support Caps transformation and use an internal buffer. This is a obviously a breaking change. Potential issue: we do not constraint the keysyms count, so what size should the buffer have?
2. Add a new API xkb_state_key_get_syms2 with a flag to set which transformation should be performed. We should probably let the user provide the keysyms buffer, much like xkb_state_key_get_utf8. Note that as stated above, we do not constraint the keysym count, so we should provide a feedback in case the buffer is too small.
3. Same as 2), but we precompute and store the transformation next to the original one, if relevant. Client does not have to provide a buffer, but it increases the keymap size.
4. Same as 2) but we allocate the resulting list of keysyms.

Option 3 seems the safest, but option 2 is more memory-efficient.