Simplifying Text Menu Patterns

Greetings All,

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:

  store(sixKeys) ['123456']
  store(A_Menu) '[À①|Á②|Â③|Ã④|Ȁ⑤|Å⑥]'
  store(A_Index) 'ÀÁÂÃȀÅ'
 
 'A' + [K_TAB] > outs(A_Menu)
     outs(A_Menu) + any(sixKeys) > use(A_Group)
 
 group(A_Group) using keys
     + any(sevenKeys) > index(A_Index, 1)
     nomatch > use(main)

Yeah, it’s not a very easy pattern to do things with. Some minor tweaks:

store(sixkeys)    '123456'
store(sixkeys_ix) ' 1  2  3  4  5  6  '
store(A_Menu)     '[À①|Á②|Â③|Ã④|Ȁ⑤|Å⑥]'

group(main) using keys
  'A' + [K_TAB] > outs(A_Menu)
  outs(A_Menu) + any(sixKeys) > use(A_Group)
 
group(A_Group) using keys
  + any(sixkeys_ix) > index(A_Menu, 1)
  1. 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.
  2. The A_Group group doesn’t need a nomatch, because it’s guaranteed to match the only rule in it.
  3. 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.

1 Like

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.

1 Like

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:

group(A_Group) using keys
  + any(sixkeys) > index(A_Menu, (ref(1) + 2) )

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 think I’d prefer to invest the energy in a better input method extension (IMX) system across all platforms :grin:

1 Like

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.

I’ve created an issue for picker/IMX support at feat(common/models): cross-platform IMX (picker) support · Issue #7928 · keymanapp/keyman · GitHub. I made sure to keep my personal thoughts toward a solution to a separate comment; I’m hoping to keep the main post to the bare essentials that define the scenarios that IMX support would be designed to address.

1 Like

This topic was automatically closed after 13 days. New replies are no longer allowed.