I’m seeking help to simply a recurring menu pattern that I have in a new keyboard. The snippet below is representative of the pattern, I end up with around 200 occurrences of it. Simplifications that I experimented with have been aimed at avoiding the group and using a single store variable for both the _Menu and _Index variables but without success. Any thoughts are appreciated:
You can assume that only keys 1-6 will get you into A_Group, and make use of that assumption to leverage the existing A_Menu store, with the sixkeys_ix store which lines up with A_Menu.
The A_Group group doesn’t need a nomatch, because it’s guaranteed to match the only rule in it.
I fixed some typos.
We hope to make ‘menu’ or ‘IME’ style keyboards more flexible in the future. See our CJK keyboards for possible directions.
If this is meant to go in a picker-style direction, this link may be of some interest:
While it doesn’t really provide something usable in-place at this point, the design notes themselves may be useful to anyone ambitious enough that wanted to push this forward early. I’d be very happy to communicate or collaborate on it.
I don’t see an issue in our main repository for it, but if this is going in the CJK-ish picker direction, these two recent posts suggest I should probably at least write up a proper placeholder issue for the idea.
I got back to refactoring and it has worked well. One thing that I wish was possible was basic arithmetic to add or subtract from an index value. Thus the extra store for the _ix padded values could be eliminated for example:
But since the 2nd argument to index is a reference to a term on the left side of > it shouldn’t be added to directly. Thus the ref function which would return the expected value for the array position of the key that has been struck.
It’s a bit much for the use case, but maybe arithmetic operations are useful in other scenarios.
I would agree with Marc, some of the functionality of a input method is very different to what the lexical models currently do. Overloading the lexical models would make it complicated to add more advanced features to the lexical model in the future.
It would make more sense to have separate methods for developing input method editors.