Wismill

> If you want to claim semver, then deleting a function requires bumping the major. Otherwise application that link at compile time will stop compiling. Similarly, dropping support for any...

> [!tip] > There is a *simple* cross-version way to check if the keymap format is supported: compile a dummy *minimal* keymap with `xkb_keymap_new_from_buffer()` and check the result. Again, it’s...

> A new major version of libxkbcommon will have to be distributed as a separate library so that check should be ineffective. A version check as you're proposing is only...

> xkb_context_new does not return an error if an unsupported flag is used. Maybe this is rather a bug to fix. See #936. > Looking at the version is all...

> These functions only return a null pointer in the error case Yeah, we do not have more details except in the log. I am trying to change that in...

> Yeah, but in practice this means instead of testing `if version > 1.20.0`, I have to construct `Context` or (worst case) `Context > Keymap > State` a dozen times...

There is only *one* value in *one* enum that is problematic ATM, and there is already a backward compatible workaround. I get your point about the difficulty for the checking...

I GET YOUR POINT. It seems you still do not get mine: 1. There is already a workaround (not great, but there) 2. Thus there is no rush. 3. Let's...

@Caellian I wrote an implementation of `xkb_is_supported_enum_value` in #942 that uses libclang for proper parsing. The difference with your proposal is that it not part of the build process, rather...

NOTE: the error message were never meant to be parsable beyond the message identifier `XKB-nnn` at the start. A better error handling would be great, but I would rather avoid...