Positioning Cursor with a Keyman Rule

Greetings,

I’d like to modify the arrow key behavior so it would move to the left or right of a composed character, rather than walk through its components. In essence:

any(Letter) any(Diacritic) + [K_LEFT] > [K_CURSOR] context
any(Modifier) any(Letter) any(Diacritic) + [K_LEFT] > [K_CURSOR] context
any(Letter) any(Diacritic) + [K_RIGHT] > context [K_CURSOR]
any(Modifier) any(Letter) any(Diacritic) + [K_RIGHT] > context [K_CURSOR]

Which is new territory for me. Does the KMN language support this?

thanks!

-Daniel

I’m realizing later, that as expressed in the original post, the [K_RIGHT] rules don’t quite make sense because the cursor is starting from the right of the context to begin with. Perhaps it can’t be expressed with the KMN language, a little closer to the idea:

 + [K_RIGHT] > any(Letter) any(Diacritic) [K_CURSOR]

but the rule only applies if “any(Letter) any(Diacritic)” is the context to the right of the arrow key when hit.

Most platforms and operating systems already cursor around ‘grapheme cluster’ combinations such as letter+diacritic. Can you outline where you are experiencing other behaviours?

Now, this is an idea we’ve discussed in the past, but it’s not on our roadmap. Currently responsibility for cursor positioning lies with the OS/application, and there is no good pathway to control it via Keyman:

  • emitting arrow key events would not work for a majority of writing systems where cursor positioning is already cluster-based
  • Keyman cannot read the current context in many applications, so this would not work there
  • Because Keyman cannot read the current context in many places, we’ve never attempted to work with following context, only preceding context (respectively, left/right in LTR writing system)
1 Like