-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core,developer): 'other' in modifiers 🙀 #11072
Comments
I need some more context on this. How is modifiers=default not bitmask 0x00000000? (Also not quite seeing how this relates to #11040?) |
This will be an additional entry in the kmap, that is, if an explicit match isn't found, try again using modifiers=X (where X is 0x10000000 as proposed). Bitmask 0x00000000 is for no modifiers which may be a different layer. <layer modifiers="none"> ...</layer>
<layer modifiers="default"> ...</layer>
That issue refactored the layers, but that's not relevant to the issue, only to the implementation. Removed the reference. |
The bitflags in question are these, right? keyman/common/include/kmx_file.h Lines 283 to 304 in dc5ac44
Those are 16 bit only, so we can start at 0x10000 for new flags in the KMXPlus code. Note that legacy .kmx only supports 16-bit because vk+modifiers are wedged into a single 32-bit value, but I don't think that's true for KMXPlus. We would need to make sure we add documentary evidence to kmx_file.h and other places where these bitflags are defined. codes.tskeyman/common/web/keyboard-processor/src/text/codes.ts Lines 9 to 45 in a404c20
kmx.ts(not unified with @keymanapp/common-types codes.ts due to history and dependency challenges, plan to unify in 18.0) keyman/common/web/types/src/kmx/kmx.ts Lines 328 to 364 in 699e1f3
legacy_kmx_file.hAnother one we want to unify but tricky, hoping to drop legacy_kmx_file.h in 18.0. keyman/common/windows/cpp/include/legacy_kmx_file.h Lines 300 to 321 in 7adc9b5
kmxfileconsts.pasAlso hopefully disappearing in 18.0. keyman/common/windows/delphi/keyboards/kmxfileconsts.pas Lines 115 to 143 in 7adc9b5
C7043_ldml.mdkeyman/core/src/ldml/C7043_ldml.md Lines 462 to 474 in 1ff2bfc
KMBinaryFileFormat.hKeyman Engine for Mac still uses this for loading kmx metadata keyman/mac/KeymanEngine4Mac/KeymanEngine4Mac/KME/KMBinaryFileFormat.h Lines 128 to 149 in 7adc9b5
etl2log load.cppShould be able to use kmx_file.h, really... keyman/windows/src/support/etl2log/load.cpp Lines 210 to 224 in a90e9f4
Related issues |
OK, i'll start with |
- add a new value, 0x10000 to indicate 'default' For: #11072
- remove default flag from kmx_file.h Fixes: #11072
- remove default flag from kmx_file.h Fixes: #11072
- at least add comments pointing back to keyman_core_ldml.ts Fixes: #11072
I feel like I've missed something here. We're saying that The closest thing I could find in the spec: https://github.com/srl295/cldr/blob/master/docs/ldml/tr35-keyboards.md#57-element-settings. I see no such reference in either https://github.com/srl295/cldr/blob/master/docs/ldml/tr35-keyboards.md#58-element-keymap or https://github.com/srl295/cldr/blob/master/docs/ldml/tr35-keyboards.md#513-element-layer at this time (as "default" is not listed as valid for either). But, |
@jahorton srl295/master is 2years out of date. Current proposed draft is: https://www.unicode.org/reports/tr35/proposed.html - click through to Part 7.
Yes. See example above. Fallback was removed. |
Note: the current draft says 'other' rather than 'default'
|
... wow, how did I miss that it was srl295/master and not unicode's master? 🤦 My apologies there. For future ease of reference: https://cldr-smoke.unicode.org/spec/main/ldml/tr35-keyboards.html#layer-modifier-matching That section clears up the reasoning; thanks. Just had to find the right reference. |
you are right! Okay- will fix.
|
Proposed.html is a stable url. The above is a staging server.
Welcome |
It's the link I reached from the URL you gave. Is a "stable" version of the precise, drilled-down link possible? The URL forwarding scheme used for stable links isn't immediately clear to me. Since the spec is so huge, it really helps to have direct links for discussion like this, hence why I included it in my comment. |
Totally understandable. I was just trying to give some caution. No there isn't a stable link to the latest drilled-down subsection. It's a gap. |
- the 'other' keyword was incorrectly called 'default' Fixes: #11072
fixed |
- add a new value, 0x10000 to indicate 'default' For: #11072
- remove default flag from kmx_file.h Fixes: #11072
- add a new value, 0x10000 to indicate 'default' For: #11072
- remove default flag from kmx_file.h Fixes: #11072
- at least add comments pointing back to keyman_core_ldml.ts Fixes: #11072
- the 'other' keyword was incorrectly called 'default' Fixes: #11072
While the modifier state property in core's API is 16-bit, internally ldml_processor supports the modifier flag LDML_KEYS_MOD_OTHER with a value of `0x10000`, which requires widening the value (we match the 32-bit size of the KMX_DWORD value from KMX+). Note: this is not yet well unit-tested. Relates-to: #11072 Fixes: #12057
While the modifier state property in core's API is 16-bit, internally ldml_processor supports the modifier flag LDML_KEYS_MOD_OTHER with a value of `0x10000`, which requires widening the value (we match the 32-bit size of the KMX_DWORD value from KMX+). Note: this is not yet well unit-tested. Relates-to: #11072 Fixes: #12057
While the modifier state property in core's API is 16-bit, internally ldml_processor supports the modifier flag LDML_KEYS_MOD_OTHER with a value of `0x10000`, which requires widening the value (we match the 32-bit size of the KMX_DWORD value from KMX+). Note: this is not yet well unit-tested. Relates-to: #11072 Fixes: #12057 Cherry-pick-of: #12281
Spec compliance:
modifiers="other"
is not supported.Could we add a bitvalue
0x10000000
(to not collide with kmx_file.h) for the 'other' fallback?(Edit it is
other
notdefault
)The text was updated successfully, but these errors were encountered: