Wismill
Wismill
> Should I deprecate unicode-data-0.4.0.1? The version bounds are too lax and might result in undefined behaviour if anyone uses unicode primitives from both base and unicode-data simultaniously. I would...
> updating the unicode version @adithyaov this is a breaking change. You should bump to 0.5 then.
Released with Unicode 15.1: - https://hackage.haskell.org/package/unicode-data-0.6.0 - https://hackage.haskell.org/package/unicode-data-names-0.4.0 - https://hackage.haskell.org/package/unicode-data-scripts-0.4.0 - https://hackage.haskell.org/package/unicode-data-security-0.4.0
I sent [an issue](https://github.com/haskell/core-libraries-committee/issues/278) to the CLC, about a new core library `unicode-data-core`.
> > if you have any pointers or resources that explain how to handle this in xkbcommon keymap traversal, I’d be really grateful! > > I think the best resource...
@Geobert In such case it should fallback to the Qwerty `VK_`s, as there is currently no support for transliteration.
Related: haskell/core-libraries-committee#278
@nbolton No, `Mod3` *usually* encodes `LevelFive` while `Mod5` *usually* encodes `LevelThree`. This is confusing but that’s legacy stuff. `Mod1..Mod5` (aka “real” modifiers) are modifiers without semantics. In theory they *could*...
> Do you mean these? Specifically the virtual modifier modifiers `*VMOD*` ones.
> This is very inconvenient because now you're forced to manually load all the symbols and check whether they exist to figure out which version you're on. There's versions that...