2-letter words not working with swipe
Kirby ·
Steps to reproduce
- Try swiping a two letter word (in, I’m, as, we)
What I expected
I expect both letters to appear
What happened instead
Often only the first letter appears. Sometimes neither letter appears. This only happens with 2-letter words.
Discussion
Sign in to comment or vote.
@Kirby 2.1.2 went live on the App Store today and the swipe engine got a lot of work since 2.1.0. Please update and try the same words again.
If short swipes still misbehave, I'd need diagnostics from your device: in the EFKey app go to the EF tab, open Diagnostics and turn on "Measure keyboard stalls". Then swipe in, I'm, as, we a few times (doesn't matter what comes out) and tap Copy records on the same screen, paste it here. It records each swipe's length, duration and whether the keyboard took it as a tap or a swipe, no text content — that will show me exactly where your strokes get cut off.
I couldn't reproduce the "in" and "I'm" case. But swiping "we" and "as" I do often times get just "w" and "a". Even though I can see the swipe trail going over both keys.
Build 422.
I’m not finding this. All those examples are working for me.
@Unmutual utual do you have more RAM? newer iPhone? right?
comment deleted
Yeah 16 pro max
(attachment)
Maybe it somehow really doesn't register as a swipe. Seeing how it just appends w without any spaces the same way as if I had tapped the key.
This worked far better in the previous version. I only noticed it in the latest version.
@muleluku your export shows exactly where it dies. The four short swipes are in the log as 1.0–1.45 keys of path length, and the tap-or-swipe check treats anything under 1.4 keys as a tap on the first key. That's why the trail visibly covers both letters and you still get just "w": w and e sit exactly 1.0 keys apart, so a precise swipe with no overshoot can never clear that bar. It was calibrated on testers who overshoot short words, and you don't.
Fixed for build 423. The length check now depends on context: an isolated swipe only needs 0.35 keys plus a quick stroke, while right after tapping letters it stays strict, so finger slips during fast typing still come out as single letters. Every one of your four killed strokes lands well above the new bar, and your traces show the decoder already handles your short we/as strokes correctly whenever they get through — top result "we" and "as" almost every time.
Your in and I'm strokes measure 2.5–3.4 keys, which is why you couldn't reproduce that part. And RAM isn't involved here at all — your log shows the neural model running, and this check happens before any decoding even starts.
Tested in build 423 - all the short two-letter words I tried are working perfectly now, 10/10. Attached traces as well.
Yeah all good here