I edited the model.ts file so that when predictive text is selected, I wouldn’t have a space after the word. This works except now I have to tap the Space bar twice if I do want to create a space after the word. I observed this on both Android and iOS devices. Can anything be done about this?
@Friedo, welcome to the community!
I’m not clear if this is related to the model or to the keyboard itself. Normally, the model doesn’t impact the behaviour of the space bar – only to the suggestions given on the top. Can you provide a little more detail so I can understand this?
Hi Marc,
Thanks for your reply.
I am referring to these instructions https://help.keyman.com/developer/13.0/guides/lexical-models/advanced/punctuation
It says at the bottom under " Customizing insertAfterWord" that it’s possible to suppress the space after the word. I thought that this refers to the space that is automatically inserted in the text after the predictive word is selected in the bar. I managed to do this by changing the code to
So now the user can, for example, type a comma or a full stop or add suffixes to the word without having to push the space bar. That’s what we want because it’s useful in this language. However, if the user (after inserting a predicted word into the text) wants to type a space, they need to hit the space bar twice. The first tap on the space bar doesn’t do anything. I wonder if this could be changed so the first tap on the space bar would indeed create a space.
Okay, I’ve found some time to download and test your keyboard + model. I am able to observe the problem, and note that it is not limited to your keyboard – it appears to be a bug in Keyman which I can see with any keyboard + model. I am opening this as an issue for further investigation.
Thanks a lot for looking at it and adding it to the list.
You’re welcome – good news is you should be able to go ahead and publish your keyboard and this fix will come through in an update to Keyman without needing any involvement from you.
Okay, yes that’s good news. Do you know when it would be? I was actually thinking to go back to the original setting (automatic space after the predictive word) and submitting the change later, after the bug is fixed.
That may not be a bad idea. We never got to implement particularly adaptive behavior here; that behavior is admittedly designed for use with automatic spaces. While you can customize the inserted punctuation, we haven’t yet implemented the ability to customize interactions with that punctuation.
We have time allotted in our roadmap a few months out to enhance areas like this, assuming that the plan is to allow these optimizations to be generalized for use under conditions like these; it’ll take some time to properly design.
What’s the status on this bug? I’ve been beating my head against this, trying all kinds of workarounds to no avail. Maybe the big goal of enhancing how rules can interact with the auto-inserted text doesn’t have to be solved in order to fix the simple issue of not ignoring the first press of space after an autocomplete?
Most South Asian languages have highly-productive suffixes, meaning that the user will start typing the bare word, then select it from the suggestions offered, and then be ready to type a suffix or select the suffixed word from the updated suggestions. This means that we don’t want to auto-insert any space after selecting a suggested word.
Also, for smart quotes to correctly determine whether you want to open or close a quote, it matters if the insertion point is sitting right next to the end of the auto-completed word or if there’s a space that’s been auto-inserted. If the user intends it to be a close quote, it’s odd to require them to hit backspace first, but it’s totally intuitive for them to hit space after the auto-completed word when they intend to have the smart-quote key then make an open quote.
Even slick English keyboards like GBoard don’t actually insert a space after auto-completing a word, but wait till they see what you’re going to do next.
It seems to me that the ideal “big” solution would permit the model to output a deadkey after an auto-completed word (and this deadkey would not interfere with the model’s ability to suggest further suffixed forms), as this would enable a keyboard to mimic GBoard-style behavior, for those who want it.
But I don’t think that functionality needs to be developed before the simple bug is fixed: All I need is for the space bar to work after auto-complete, no special interactivity with KMN rules required.
1 Like
This bug is scheduled for investigation and hopefully correction in the next two weeks. I’ll make a note about your comments on the tracking issue.
1 Like
One related issue: For a keyboard that is not going to insert some separator character, I don’t see the point in devoting one of the 3 suggestions to what’s been typed so far. If that’s what the user wanted, he’s got it already; no need to click that suggestion. Is there a way we can have all 3 suggestions to be predictive alternatives to what’s been keyed?
1 Like
Update today: after planning for the current two week sprint on Monday, we realised that we probably won’t get this issue addressed this sprint as we are still working on improved correction suggestions.
This work is still in the schedule for 14.0, but may be a bit more than 2 weeks away.
This topic was automatically closed after 13 days. New replies are no longer allowed.