Context rules not correctly swallowing context

Keyman
,
1

I have set up a keyboard with the following rules:

store(tone) "^ˇ´`˝"
store(dia) U+0302 U+030C U+0301 U+0300 U+030B

any(tone) + [RALT K_LBRKT] > 'ɔ' index(dia,1)
any(tone) + [K_E] > 'e' index(dia,1)

The rule with “e” works as I think it should, turning pre-typed tone markers into diacritics (´ + e > é, etc).
However, the rule with “ɔ” works in some environments (in debug mode in keyman, and in ms word), while it results in “´ɔ́” elsewhere (in test mode in keyman, and in paratext). I cannot see that there should be any difference between the two rules - but at any rate, I would expect them to produce the same errors in all apps.

2

Welcome to the community! I don’t see anything wrong with your rules. Do you want to send me your keyboard via direct message? (I guess zip up what you have and upload it somewhere and give me a link?)

Update: Oh, you must have some other rules for producing the characters in store(tone) because those aren’t on standard keyboards. Maybe we need to see those rules.

3

I am unfortunately unable to upload attachments, as a new user.

I think these rules are pretty straightforward:

+ [SHIFT K_RBRKT] > '^'
+ [K_EQUAL] > '´'
+ [SHIFT K_EQUAL] > '`'
+ [RALT K_EQUAL] > "ˇ"
+ [SHIFT RALT K_EQUAL] > "˝"

It seems the problem occurs only when RALT is required for the vowel. If I make it required in the rule for e, it produces the same error as for ɔ. And ɔ is correctly produced when RALT is not a part of the key combination.

4

Do you have a + in front of those rules? Whatever you have changes to a bullet, so it’s hard to see. I would think a keyboard like this would work fine. In this case, I’m not sure if the order of the rules would make a difference.

store(&VERSION) '10.0'
store(&NAME) 'Test'
store(&KEYBOARDVERSION) '1.0'
store(&TARGETS) 'windows'
begin Unicode > use(main)

store(tone) '^ˇ´`˝'
store(dia) U+0302 U+030C U+0301 U+0300 U+030B

group(main) using keys

   + [SHIFT K_RBRKT] > '^'
   + [K_EQUAL] > '´'
   + [SHIFT K_EQUAL] > '`'
   + [RALT K_EQUAL] > 'ˇ'
   + [SHIFT RALT K_EQUAL] > '˝'

any(tone) + [RALT K_LBRKT] > 'ɔ' index(dia,1)
any(tone) + [K_E] > 'e' index(dia,1)
5

Which version of Keyman (and Keyman Developer) are you using?

6

Yeah, you’re right, there was a + at the beginning of each line.
I copied your code into keyman, and I get the very same problem (´ɔ́) in test mode.

I am already in the process of downloading the latest version of Keyman Developer to see if anything changes. (I am on Keyman Developer 13.0.102.0. Keyman was updated this week.)

7

It’s important to keep Keyman Developer and Keyman on the same version. Version 14 has significant improvements to modifier key handling, so recommend working with version 14.0.281, released this week.

(The requirement that Keyman and Keyman Developer be the same version will be relaxed in v15 and later, when Keyman Developer will no longer have a dependency on Keyman.)

This presentation issue in the forum can be avoided by surrounding your code with ```, which presents your code as code rather than formatted text.

8

Updating Keyman Developer resolves the issue.

1 Like