Autocorrect missing spaces and improve spacebar functionality
Ed MOD ·
Wish:
Improve spacebar functionality.
Why:
I see myself a lot of times missing the spacebar in the EF keyboard. I'm sure I hit it but words are sticked together. It's literally a hit and miss. This hardly happens in the native iOS keyboard. It happens on all languages I use on ios27 and phone 17.
Then there is an additional wish:
Both SwiftKey and Gboard autocorrect missing spaces, which sometimes happens with misclicks around the spacebar. See the screenshots. This wish is the same that Tomás logged as a bug on discord, so one can be closed. See screenshots.
I do add a bit of info I looked up on Claude:
space key taps are not registering
Symptom: pressing the spacebar produces no character, intermittently, mainly while typing at speed with thumbs.
Likely causes:
- No dynamic hit-target adjustment. Apple's keyboard resizes key hit areas based on predicted next characters. If your implementation uses only the literal button frames, near-misses on the space key produce no input.
- Multi-touch not handled. During fast typing the space touch begins before the previous key's touch ends. If only one touch is tracked at a time, the second is discarded.
- Using touchUpInside rather than touchesBegan. A thumb press on space usually includes slight movement. If the finger drifts outside the button bounds, iOS cancels the event and no character is inserted.
- Bottom-edge gesture conflict. The home indicator region delays or intercepts the first touch. Keys placed against the bottom edge of the keyboard view are affected.
- Extension memory limit. Keyboard extensions run under a low memory ceiling. Exceeding it causes a silent reload of the extension, dropping in-flight input.
Suggested fixes: custom hit-testing on touchesBegan with full multi-touch support; a space-key touch region larger than its visible bounds, extended upward and laterally; and bottom-row keys inset from the screen edge.
Discussion
Sign in to comment or vote.
@Ed both of these are in build 407.
The spacebar first. I found a few spots where a tap on it could get dropped: mostly right at the bottom edge, and when you're typing fast with both thumbs and the touches overlap. A low tap just under the spacebar wasn't registering at all, so I pushed its touch area down to the edge, and the space no longer gets thrown away when the system cancels the touch or when the next key lands before you lift off. That's the "I'm sure I hit it" case.
The missing space: when you clip b/v/n instead of the spacebar and the two halves are real words, it now drops the space in. so hevis becomes he is, akosa becomes ako sa. it only does that when both sides are actual words, so it won't split a name or a word it doesn't know.
One caveat. I couldn't get the spacebar drops to happen in the simulator, they only really show up with real thumbs, so once 407 is out I'd want to know if it's clearly better for you or if you can still make it miss.
Looking forward to 407!
I just quickly tried "hevis". With auto-correct on, it show "he is" as the middle, be suggestion and applies that when I hit space.
With auto-correct off, it would be nice to still get "he is" as a suggestion, currently I don't get that.
Or is that a whole different thing in the inner workings of the machine, should I create a separate suggestion ticket for that?
@muleluku yeah that's a separate thing, mind opening it as its own suggestion? showing the correction in the bar when autocorrect is off is a different path from the auto-apply one, cleaner to track on its own.
I want to get this update out as soon as possible, so I'd rather close this ticket. the spacebar and the missing-space part are both in. the bar-suggestion-when-off idea I'll pick up after.
I now realize that in B119 I forgot to mention it's in suggestions and not autocorrect...
First impression is a gazilion times better! Amaaaaaazing! Will test more!! Excellent work @efko
I do indeed type with both thumbs all the time. The amount of errors due to spacebar errors is literally 90% less, irrespective of language set. Maybe it's even as good as native niwm. Great improvement, and if it's up to me, this topic for the spacebar can be closed. @efko
I do have autocorrect off as my guess is the alternative language's dictionary is not the same quality as the English one and a lot of words were corrected incorrectly. I'd prefer the autocorrection suggestion to be present in the suggestions list but not applied automatically.
@CEE Please create a separate ticket for this. And also another ticket if you have a problem with any language.
<https://feedback.efkey.app/r/S82>
Follow up ticket created for new suggestions: #S78
@muleluku I built the autocorrect-off version too, so I deleted the separate ticket and folded it back in here. with autocorrect off, when you clip b/v/n instead of space and it makes two real words, you now get the split as a suggestion chip instead of it being applied for you. so "hevis" gives you "he is" to tap. it's in the next build, 408.
I knew you couldn't resist tackling it right away :D
How is it supposed to work? So we know what to look for while testing, what to consider correct or incorrect behaviour.
Should it recognice any two known dictionary or learned words connected by v/b/n (no c? Maybe my spacebar is longer...) and suggest them to be split?
@muleluku ha, guilty :D
it fires when what you typed isn't a real word by itself but splits into two words that are both in the dictionary: "hevis" → "he is", "akosa" → "ako sa". one half not a dictionary word and it stays exactly as typed, so no chopping up names or random typos. dictionary words only for now, not ones you've taught it.
the joining letter is whatever sits over the spacebar, so c and m too, not just v/b/n. that's the letter you aimed at as space, so it gets swapped for it.
in the bar your typed word stays in quotes (nothing applied) and "he is" shows next to it as a chip to tap.
Understood.
For autocorrect it makes sense that both parts must be valid dictionary words. We want to be certain the correction is correct. And also autocorrect kicks in only when then whole word cluster is committed
For suggestions without autocorrect enabled, or even with autocorrect while still typing, it might makes sense to offer the split chip, if the whole word is unkown and the first part is known. The second part might just be an unfinished word.
We could then tap to split and continue typing the second word (no space to be inserted upon typing after chip selection in the case of an unknown second word). And with the split we get corrections and completion suggestions while finishing the second word as well.
But that's probably a thought for future iterations or its just too complex to be worth considering.
and most importantly, we need to save RAM.
Second thought: do you look up what the letters above space are dynamically or are they hardcoded? My thought is, does this work with non Latin keyboard languages?
@muleluku dynamic. it goes off your actual layout, so it's whatever letters physically sit over the spacebar in the language you're using, not a hardcoded v/b/n list. switch layout and the set moves with it.
non-latin: the part of the engine that does this handles non-latin scripts too, so it's not latin-only by design. same rule though, both halves have to be real words in that language's dictionary. i haven't specifically tested it on a cyrillic/greek/etc layout for this, so i wouldn't promise it until someone does.
I tried a few combinations with
this an
this can
this and
jet fuel
something longer
and x c v b n m in between.
Only EN active, autocorrect off.
It's very hit and miss, whether I get a suggestion to split. Interestingly, the same combination sometimes does produce the chip, sometimes it does not. It feels like with v I have the highest success rate.
Also, mixing languages is not supposed to work, I guess? Tried combinations with "ich want" and "ich like", never got the chip.
Comment by @glowhunter from #B119 :
From what I understand it does:
but what frequently happens to me is I hit letters from the lower row instead of spacebar:
"inbthis" or "invthis" should be corrected to "in this"
Sometimes "." too:
"in.this"
or in Hebrew:
"לימאת" should be corrected to "לי את"
@muleluku @glowhunter build 422. I found why it was a coin flip: the split was decided by how close your tap landed to the spacebar, so the exact same letters would give you the chip one time and nothing the next. v sat closest so it hit most often, b was too far out and usually missed. that's the "same combination sometimes works" you saw.
now there's a second path that ignores where you tapped. if what you typed isn't a word on its own but breaks into two real words, you get the same chip every time. so invthis and inbthis both give "in this", and inthis with no letter at all does too. it only fires when there's one clear reading. thisvan I left alone on purpose, because "this van" is just as real as "this an", and without knowing where your thumb landed I can't tell which one you meant, so I'd rather show nothing than guess wrong.
still suggestions only, autocorrect stays off, nothing gets applied for you.
two things I'm not doing here. mixing two languages (ich want) still won't split, the halves get checked one language at a time and that's a bigger change. and the period case (in.this) and Hebrew aren't in this build. I was wrong earlier when I said the non-latin side already handled splits, it doesn't actually run there yet, so hebrew won't split for now. those two I'll pick up on their own so this one can move.
Splitting works well now.
But found an issus with blocked words.
With EN active type "tryin" and get "tr in" suggested.
Add "tr" to blocked words → "tryin" still gives "tr in"
And probably a separate issue, but I guess "tr" shouldn't be part of the dictionary in the first place. It does come up bold in the suggestions when typed (before blocking it)
@muleluku two bugs here, both fixed for build 426 (and 2.1.3 on the App Store).
blocking never reached the split. the check compared the whole chip "tr in" against your blocked list, so a blocked "tr" never matched. now each half is checked on its own, and if either one is blocked the split isn't offered or applied. that covers autocorrect on too: before, blocking "is" still let "hevis" turn into "he is".
"tr" is in the English dictionary, but at the lowest frequency level there is. the split used to accept any dictionary word as a half, now both halves have to be common words, so "tr" and the other junk two-letter entries can't form a split anymore. he is, in this, it is, of the, to be, ako sa all still split. I'm leaving "tr" in the dictionary for now. pulling one word means rebuilding the whole English dictionary, and once you block it, it's no longer bold anyway.
are you on QWERTZ? the letter between "tr" and "in" was the y, and y only counts as a missed spacebar on a layout where it sits in the bottom row. on QWERTY "tryin" never gave that chip.
So, I got the feeling again that the spacebar doesn’t respond to my thumb in the same way the native keyboard does. In the attached video I’m quite sure that I’m hitting the spacebar on about the same spot. Native almost catches them all, efkey doesn’t. I’m sure it worked better before
Reopened for analysis of Ed's latest report
@Ed holding the spacebar a little too long (0.3 s) quietly switched it into cursor mode, and letting go of the cursor never typed a space, even when the cursor hadn't moved. A deliberate, slower tap like the ones in your video crosses that easily, while a fast thumb tap usually doesn't. Fixed for build 438 (and 2.2 on the App Store): if the cursor didn't move, letting go now types the space, and if one still goes missing, a Diagnostics export will show me exactly where it went.
Is it on 438 or the just released 437? @efko
@Ed I'm already working on 438
Wow, amazing work! Looking forward to testing it!
@efko I am still seeing "in.this" and "לימאת" without suggestions.
now I typed slowly and in blue words that sticked together and where I expected a spacebar. Can you check diagnostics or do you need more? @efko
@Ed your 438 export has no trace of those missing spaces, so they weren't lost in cursor mode and the touch wasn't cancelled. They got dropped somewhere the log didn't cover yet. Build 439 (and 2.2 on the App Store) logs the two remaining spots where the keyboard throws a tap away, so when it happens again, send me a Diagnostics export right after. dathet won't become dat het in Dutch on purpose: Dutch glues words into compounds all the time, like toetsenbord, and splitting unknown words would break more than it fixes.
@efko whereas "invthis" -> "in this" works, my cases are still uncorrected as of b452:
@glowhunter with the period key on, m sits over the period instead of the spacebar, so it never counted as a missed space, and with autocorrect off the split only showed up when your tap landed close to the spacebar. Fixed for build 454 (and 2.2.1 on the App Store): inmthis, inbthis and invthis now give an "in this" chip right after your word, wherever on the key you hit. in.this stays as typed on purpose since a period between two words is too often meant (file.txt, domains), and Hebrew splitting is still off, that one I'll do separately.
@efko I am.really sorry. I keep pressing "." instead of space. Like, a lot. Much more than I type filenames. I suspect manyother people also. Perhaps add this with an option to turn off, for those inclined to type filenames?
@glowhunter it's in as a LAB switch, Period instead of space, on by default, so anyone who types file names can turn it off in EF › LAB. Fixed for build 456 (and 2.2.1 on the App Store): with autocorrect off in.this gives you an "in this" chip right after the word, with autocorrect on the space turns it into "in this" by itself, and backspace right after brings in.this back.
This only works with auto correct off. With auto correct on, in.this stays as is after hitting the space. Of course one can tap on the suggestion shown in the bar in both cases. Reopening to check why it doesn’t work with auto correct on.
@ilikered the period only kept track of where you tapped it when the word before it was typed letter by letter, so after a swiped "in" the space had nothing to go on and you got just the chip. Fixed for build 457 (2.2.1 on the App Store): swiped word, period next to the space bar, "this", space now gives "in this", and backspace right after brings "in.this" back. If you were tapping "in" rather than swiping it, or took the period from the 123 layout, tell me, those cases behave differently.
@efko it does work in 456, most of the time, I still haven't figured out the pattern of when it doesn't.
Circling back to Hebrew - what is the reason it's a separate challenge? Do all languages have bespoke splitting rules?
I thought this was just 1) identify keys adjacent to spacebar 2) does current "word" match "AKB" pattern for A,B ∈ { Dictionary words } and K ∈ { spacebar adjacent keys }
Is it more complex than that?
Still doesn’t work with auto correct on.
in.this followed by space stays as is and doesn’t get split to in this.
@ilikered the split only ran when the space confirmed a tapped word. When "in" or "this" was swiped, or the period ate the automatic space after a swiped word, the space kept "in.this" and the split stayed as a suggestion in the bar. Fixed for build 459 (and 2.2.1 on the App Store): the space splits it in those cases too, and backspace right after brings "in.this" back.
Just to clarify, I wasn’t swiping either in or this, I was just typing in.this and hitting the space. With autocorrect on, the expectation was for the in.this to get corrected to in this, however it stays as is.
Works as described.
@efko Hebrew still not fixed, should I open a separate ticket?
Open pls
Reopened for Hebrew language @glowhunter
Please open a separate bug for Hebrew issues.
Opened #B467 for Hebrew