Topic Catchalls.

I was pondering your idea of Nomatch(All).

   Is this the wrong place for this type of test? Match and Nomatch are catchalls for the Rules of the Group they are in. To me, it seems a more logical to have 'All' in Any(All). 'All' in this case would be all possible keys within a particular hardware/operating system configuration. 'All's would cover all possible modifiers of all possible keys: Shift, Left Shift, Right Shift, Ctrl, Left Ctrl, Right Ctrl, Alt, Left Alt, Right Alt, AltGr, Caps Lock.

   This may suggest other uses for types of 'All':
      AllGlyphs             Any possible displayable symbol.
      AllCursorKeys      Up, Down, Left, Right, Page Up, Page Down, Home, End.
      AllTextEffectors   Tab, Enter, Backspace, Delete, Insert, Caps Lock.
      AllNumericPad     All the keys on the numeric key pad.
      AllFunctionKeys   All possible function-keys.
      AllSpecials           Esc, Num Lock, PtrSc, SysRq, ScrLk, Pause, Break.
      AllModifiers          All modifiers listed above.

   This also suggests the syntax 'NotAny(All…)'.

   This would allow the reliable matching of whole sections of the keyboard. Allowing code like:

:

+ [K_UP] > …  + [K_DOWN] > …  + [K_RIGHT] > …  + Any(AllCursorKeys) > nul

   Meaning the Up, Down, and Right cursor keys will have a function but no other cursor movements will function.

   To trap all possible modifiers of a key:
      AllModifiers   Could be used as

:

+ [CTRL K_ENTER > …  + [AllModifiers K_ENTER] > nul

   Meaning Ctrl Enter has a function but no other modified Enter will work.

Regards
Julian Griffin

Yes, that's a feature I have discussed in the past with others; it could be useful, although mostly as a way of blocking keystrokes rather than for actual input.

Agreed. But inhibiting keys can be as important as emitting keys.

   In my case, I wish to allow the user to enter, what might loosely be called a 'phonetic spelling', of just a few words, not long text. TPA's phonetic graphemes are very tightly defined. The only valid graphemes are for the 45 phonemes of English and a TPA space. No other symbols, punctuation, numbers, or glyphs are valid. So, in Grapheme Input Mode (GiM), the only valid keys from the keyboard are the 26 Latin letters, the Modifiers: Shift, Ctrl+Alt, & Shift+Ctrl+Alt or (AltGr, if I can ever get it to work), a Space, and a Starting & Ending key. So, whilst in any WIMP system, this type of modal control is rarely achievable, and particularly not from just the keyboard control (TSF?), limiting what can be done from the keyboard is a good start.

   So if I create a Group that defines input protocols for the 45 graphemes, Space, Start & End. I would then like to inhibit all other key presses. So code something like {this not valid code, just an exemplar}:

:

Group(GiM) Using Keys  + 'A'             > Grapheme1  : {Modifiers} 'A' > Grapheme2  :      :       :  > Grapheme44  : 'Z'             > Grapheme45  + Any(OtherKey)   > nul

   This would allow me to use/utilize just the keys I wish and dump all other keyboard activity.

   So yes, I agree, this would be of most use in inhibiting key presses or to put it another way, mandating only the keys the keyboard designer wish the user to be able to access.

   There seems no reason, to me, to use the 'All's in Outs(), Index(), Notany(); but:

:

+ Any(ALL) > … … + Any(ALL) > … Any(ALL) + … > …

   Would all seem valid.

   But I am not sure that Any(ALL) > … in a Context Only group makes and real sense.

Regards
Julian Griffin.

So, the difficulty is blocking keys that are not character keys is not a helpful user interface pattern. A user may wish to press Esc at any time to cancel a dialog. Or press F1 for help. Or the keys may have other meanings that we cannot be aware of. For character keys, it is reasonable for an input method to block them in specific situations, but it isn't really reasonable to block all other keys in the same way.

Have I got the right end of the stick?