Declaring keysyms via strings

[mahkoh]

Consider the following:

    key <AD11>	{[ udiaeresis, Udiaeresis,   dead_diaeresis, dead_abovering ]};

I believe it would be useful to allow this to be written as follows:

    key <AD11>	{[ "ü", "Ü",   dead_diaeresis, dead_abovering ]};

With the following semantics:

1. The string must contain a number of unicode code points.
2. If the string expands to 0 code points, the resulting keysym is NoSymbol.
3. If the string expands to 1 code point, the resulting keysym is the output of xkb_utf32_to_keysym.
4. Otherwise the string expands to { ... } with each code point converted via xkb_utf32_to_keysym.

This syntax can also be used in nested position to be able to mix unicode and non-unicode keysyms:

    key <AD11>	{[ "ü", "Ü",   { "example", dead_diaeresis }, dead_abovering ]};

In this case the keysyms are embedded directly into the outer { }.

[wismill]

I like the idea. It feels more natural, and it is what I proposed in #546 for the new transforms section. But it we do this, we must enforce the string encoding. Currently the only requirement for XKB files is “ASCII compatible”. Compose files do require strings to be encoded in UTF-8.

[wismill]

See #639 for an implementation.

[wismill]

We could extend this to Compose as well, although there may be multiple implementations used simultaneously with different support. E.g. Gtk and IBus only support a very limited keysym syntax.

[bluetech]

The idea looks nice to me as well. I'd be curious to see some real keymap converted to this syntax, if someone feels like putting one together.

This syntax can also be used in nested position to be able to mix unicode and non-unicode keysyms:

I'm less sure about this. The example given is confusing to me.

[bluetech]

If that's the way that you want to go

I'd like to hear yours and @wismill's opinion -- I prefer the single-codepoint limitation but you and @wismill can definitely override me if you disagree.

then I'd suggest not erroring out but emitting a warning with a graceful fallback since it's easy to violate this rule accidentally.

I somewhat prefer to be strict in such things, presumably if someone wrote it and they get a clear error they'd just fix it?

---

Another idea if we choose to go with single codepoint is to use 'A' instead of "A" so it gets its own token type, and resemble the char/string literal distinction is several programming languages. Either proposal is not backward-compatible so new syntax should be fine.

[mahkoh]

I somewhat prefer to be strict in such things, presumably if someone wrote it and they get a clear error they'd just fix it?

My approach to user-facing configuration is to be as graceful as possible. For example, in the configuration of my compositor, which uses toml, I'm using a toml parser that recovers from many syntax errors. This is because restarting the compositor and then having no keyboard shortcuts available is worse than getting a warning with most shortcuts still working as desired. That also makes it easier to fix these issues since you first need a working system to do so.

[wismill]

What about:

• 'x' for a single code point, everywhere a keysym is expected.
• "abc" for any code points count, as a syntax sugar for {'a', 'b', 'c'}. Nesting disallowed. Only valid in the context of key symbols. User may use ['a'] or ["a"] indifferently, but ['ab'] is invalid.
• No Unicode normalization, it’s up to the user. People using combining characters probably use an IM anyway, that normalize the input. If not they probably want the sequence unaltered.

I expect the use cases only for single quotes to be very limited anyway. So maybe we do not need them at all, because it is already always possible to use the usual keysym name or the Unicode keysyms Unnnn.

In the end what really matters it not what we – XKB lib devs – find easy to parse or rigorous, but what makes XKB easier to customize for people. Not everybody is a power user or a seasoned XKB hacker. This euphemism is what I had in mind with the keysyms strings for the new transforms section in #546.

So I guess that by the principle of least astonishment we should stick to only double quotes and allow them everywhere at least one keysym is expected, nesting included.

[mahkoh]

FWIW I prefer not to introduce a new token type.

[bluetech]

OK, it sounds like you both agree, so we should go with the original plan -- allow using strings for keysyms, of any length, also in nested position. No new single-char token.

[wismill]

Implemented in libxkbcommon 1.9.