feat(android): accepting a suggestion then adding punctuation should delete automatically added space

[mcdurdin]

Is your feature request related to a problem? Please describe.

From a team review of the Keyman for Android UX (https://github.com/keymanapp/keyman/issues/7161)

When using a lexical model that inserts spaces after an accepted suggestion, it's annoying to have to press backspace before adding punctuation such as full stop.

Describe the solution you'd like

Ideally, delete the space before inserting the punctuation, then re-insert the space after the punctuation.

Unfortunately, this is probably not trivial to solve -- the keyboard itself does not know that the LM inserted the space, so it's not really possible right now to do a special case for punctuation in the keyboard code. Likewise, the LM has no control when the punctuation is typed, so it can't automatically delete the space in this situation.

Furthermore, this is language-specific behaviour: not all LMs insert spaces; some insert ZWSP, or nothing at all after a suggestion.

Per @jahorton: Will need predictive-text design work to properly addressed - pretty sure it’ll need language-specific (or script-specific) data to be defined on the lexical model.

Related issues

---

Keyman for Windows/macOS/Linux/iPhone/iPad/Android:

• Device: Samsung A90 5G
• OS: Android 12
• Keyman version: 15.0.269-stable

[jahorton]

I think some of the adjustments (and notes for future work) I have as part of #7205 may be helpful for this. See my notes starting here: https://github.com/keymanapp/keyman/blob/6c50de9e9a220f28c49050dae44e6f3e01ef7a18/common/web/lm-worker/src/model-compositor.ts#L159-L177

A similar strategy could be used to detect if we'd tokenize without the space there - "if so, why add a word-breaking space"?

[rowbory]

In NaijaType I built in rules to my keyboard to address this with the most common punctuation: ,.!? Could it be a suggested block of code that keyboard-makers could add to their keyboards and customise as needed?

[mcdurdin]

@rowbory, yes this is a good idea. We'll consider this as part of any future solution.

[ermshiperete]

What if the LM would insert a kind of dead-key that gets ignored when a punctuation key follows and turns into space or whatever when any other key is typed?

[mcdurdin]

Yeah, some special marker might be a way forward? I'd include the space with the suggestion, but then have the following keyboard pseudocode:

accept() > 'word' dk(__suggestion) ' '    c matching what is inserted by the LM

dk(__suggestion) ' ' + any(punct) > index(punct, 3)

[MakaraSok]

This looks like a small issue, but, from a user point of view, it's a turn off. It is funny to press a backspace every single time a punctuation is added after a word is picked of the banner.

If there is a voting system for this to be fixed/added, I'd like to vote for this one. Can we have this done soon as it was first posted two years ago?

[mcdurdin]

@MakaraSok I agree it is annoying. We'll put it into the 18.0 triage. We have not had anyone working on the predictive text module for a while. But as @jahorton is working on predictive text for v18, there is a good chance we can get onto this.

[jahorton]

... I just had an idea for it that shouldn't be terribly hard to implement for reversing the space. We could add a spot on returned suggestions for specifying whitespace deletion.

The issue, though: which keyboard characters are punctuation, again? We'd need a way to say which characters trigger the auto-delete and which don't... which makes more sense on the model, rather than the keyboard. That opens up issues we'd definitely need to design for. I'm thinking a whitelist approach would be better than a ~whitelist~ blacklist approach, but that's only a small part of the overall picture.

[ermshiperete]

...a whitelist approach would be better than a whitelist approach...

What???

[jahorton]

We're noticeably closer to this with recent improvements for 18.0, but we're not all of the way there yet. I forgot about this issue, so I kind of wrote it up again as #12013... though there are a few related ideas that don't perfectly match this issue documented there as well.

[mcdurdin]

I forgot about this issue, so I kind of wrote it up again as #12013... though there are a few related ideas that don't perfectly match this issue documented there as well.

Can you consolidate any other content from this issue in #12013 and close this one out so we can reduce clutter?

[rowbory]

This looks like a small issue, but, from a user point of view, it's a turn off. It is funny to press a backspace every single time a punctuation is added after a word is picked of the banner.

If there is a voting system for this to be fixed/added, I'd like to vote for this one. Can we have this done soon as it was first posted two years ago?

My solution is the following kmn code:

U+0020 + ',' > ', '
c Also auto-shift layer when we type an end of sentence
'. ' + U+0020 > '   ' c Turn 3 or more spaces into 3 spaces because we clearly really want that.
U+0020 + U+0020 > '. ' layer("shift")   c Double space is end of sentence.
U+0020 + '.' > '. ' layer("shift")      c Full stop after space should be switched.
U+0020 + '?' > '? ' layer("shift")      c Same with question mark 
U+0020 + '!' > '! ' layer("shift")      c Switch space before exclamation to be space after it.

The down side of this I notice when I have that keyboard running and I try doing something like typing rm .hg which turns into rm. hg. But it's not a big problem.

I do like the idea of the prediction model spitting out a deadkey that turns into a space when anything but a space or list of "don't add a space before me" characters are typed. At least until anything is done in the engine the code above can be added to any keyboard to make it less annoying for end users.

[mcdurdin]

@jahorton This probably belongs to you, not sure if it fits in with your current work. We can triage together later.