Lexical models break variable stores (At least for mobile keyboards)

A simple mobile keyboard that uses variable stores gets bad values in those stores if a lexical model is present. This happens both on the Android (e.g. in Keyman app or in a KAB app) or in a browser window (simulating a mobile device) testing the keyboard and lexical model.

The KMN file contains this (after the system stores):

store (myVar) "1"

begin Unicode > use(main)

group(main) using keys

+ [K_S] > "(+)" set(myVar="1")    c  S will Set the variable, and output (+)
+ [K_C] > "(-)" set(myVar="0")    c  C will Clear the variable, and output (-)
if (myVar = "1") + [K_R] > "+"    c  R will Reveal the variable's state with + or - 
if (myVar!= "1") + [K_R] > "-"

A touch layout provides buttons to send K_S, K_C, and K_R.

Let’s suppose you type: SRRRRCRRRR

Without a lexical model present, you get the expected output:

(+)++++(-)----

But if a lexical model is present, even the starting model with no changes, the output is this:

(+)-+++(-)++++

That is, after setting the variable, the first reveal shows that it’s cleared, and thereafter shows that it’s set. And after clearing the variable, it always shows that it’s set.

I need to be able to take advantage of variable stores in my keyboard, but I don’t want to lose the predictive text. Any help in this matter would be greatly appreciated. Thank you!

Here are a bare-bones keyboard and a bare-template lexical project to demo this:
Projects.zip (19.8 KB)

@joshua_horton this sounds like one for you to dig into!

Yep, sounds about right. We’re already aware of this issue and have been tracking it here: https://github.com/keymanapp/keyman/issues/2924. We’ve already resolved the persistent load and store aspects for 14.0, but setting and clearing are more difficult due to how they’re currently implemented.

Unfortunately, any fix for this is unlikely to be backported to 13.0 due to the underlying issues involved.

1 Like

The following pull request https://github.com/keymanapp/keyman/pull/5749 finally addresses this issue in Keyman 15. I’m sorry it’s taken so long to get to this – the fix ends up being relatively straightforward.

1 Like