bug: Korean-compatible shifted vowel forces 말할까 to raw English akfgkfRK #12

Activity

1. helloiamnotth3devnicetomeetyou commented on Oct 22, 2026

   

   helloiamnotth3devnicetomeetyou

   on Oct 22, 2026

   Contributor

   More actions

   Thanks for the reproduction and root-cause analysis. I confirmed that akfgkfRk and akfgkfRK compose to the same Hangul reading, but the final uppercase K causes the latter to be classified as English. Esc recovers the Korean reading.

   I'll adjust the uppercase classification rule to account for Korean composition when Shift overlaps the following vowel, while preserving the original key stream, genuine English capitalization, and meaningful Korean shifted keys. This will be handled separately from #11.
2. snowykr commented on Oct 22, 2026

   

   snowykr

   on Oct 22, 2026

   ContributorAuthor

   More actions

   Thanks for confirming the reproduction. I investigated a conservative fix and then tested its generalization more aggressively. Posting the results here because the remaining failures are not limited to invented words, and the broader alternatives I tried introduce a real English-preservation tradeoff.

   Conclusion: my candidate provides a limited improvement, but I am not proposing it as a general solution to this issue. The issue remains reproducible. These experiments were based on 82add6290e7d6b1dc450af551277bed7153585b0; they are not an assessment of any subsequently implemented upstream fix.

   1. Candidate and initial checks

   The candidate relaxes the uppercase-English shortcut only when:

   • an unchanged uppercase vowel immediately follows a meaningful shifted Korean consonant (Q/W/E/R/T), with lowercase letters elsewhere in the token;
   • Korean is enabled;
   • the existing Korean word/vocabulary/inflection checks recognize the composed token.

   This only permits score competition; it does not force Korean. Original keys and capitalization are preserved, meaningful shifted vowels/consonants are not flattened, and the exception does not admit an unrelated Japanese reading. There are no word-specific exceptions.

   The implementation and evaluator are available for inspection on my fork:

   • Candidate and evaluator: 4abd379
   • Snapshot-comparator validation: 515b028
   • Evaluation documentation

   It fixes the clean-profile reproductions akfgkfRK → 말할까 and dlfWLr → 일찍.

   The initial evaluation covered 145,344 rows / 435,948 decision or session-output surfaces across enko/enkoja and development/holdout groups, with 5,292 improved surfaces and no newly wrong sampled surfaces. The evaluator used independently specified expected outputs, composition-preserving augmentation, canonical-key grouping before splitting, exact-case English identifier controls, and real InputSession replay for contextless rows. New wrong outputs were counted separately from improvements, rather than hidden by a net score.

   Important limitation: these are repeated surfaces/contexts/profiles, not that many independent words. Key-group holdout does not make the corpus independent of the dictionaries used by the engine. The favorable result did not establish generalization to unfamiliar words or productive forms.

   A local installed macOS build also completed a final 69-case OS-key smoke matrix: textarea 23, contenteditable 23, and fresh NSTextView clients 23. The driver posted virtual-key events, including holding Shift across adjacent uppercase keys; it did not insert expected Unicode text for the IME cases. Marked and committed text were checked. That build also included the separate #13 guard. These were selected smoke cases, not human keyboard-timing measurements, an all-app claim, or a matched-profile before/after study. Their success should not be mistaken for unseen-word coverage.

   There is also a measured cost, not a speed improvement: focused partial-decision benchmarks on affected paths added roughly 1.1–1.8 microseconds in the tested configurations. This is not end-to-end keyboard latency.

   2. Ordinary forms still fail

   Further manual exploration included 늘찍 / smfWLr as a deliberately possibly-nonstandard input. I then constructed a new challenge set containing 85 ordinary expressions/forms and generated single-overlap variants. Each generated variant was checked to compose to the same independently specified Hangul as its canonical keys.

   With no learned data, no previous-language context, and final decisions:

   Check	Correct output
   Canonical input for the 85 ordinary forms	85/85
   Their 119 Shift-overlap variants, current candidate	58/119

   The results were identical in enko and enkoja. The current candidate also remained at 58/119 with previous English or Korean context.

   Examples with the candidate:

   Intended Hangul	Overlap keys	Actual output
   늘찍	smfWLr	smfWLr
   널찍하다	sjfWLrgkek	sjfWLrgkek
   늘씬하게	smfTLsgkrp	smfTLsgkrp
   쌀쌀해요	TKfTkfgody	TKfTkfgody
   깎았어요	RKRdkTdjdy	RKR았어요

   The corresponding canonical inputs produce the intended Hangul. The ordinary-form rows show that this is not just a question of whether an invented word deserves automatic conversion.

   This is a handcrafted diagnostic set, with related forms/stems, not a representative error-rate estimate or a newly blind holdout. Its purpose is to expose counterexamples to the generalization claim.

   I also cross-checked difficult examples through the actual C FFI using the previous #13-only build and the combined candidate, enko/enkoja, Enter/Space, and isolated clean, generic-shape, or explicit-word learning states: 288 recorded replays, including failures, not 288 successful Korean corrections. The failures above reproduce in clean sessions; explicit word overrides remain effective.

   3. Why these failures occur

   For smfWLr, the underlying raw scores favor Korean (approximately ko=-2.42, en=-5.09). The composer produces 늘찍 correctly.

   However, the candidate's lexical predicate is false, so HeuristicEngine::decide() returns the early English decision with confidence=0.99, runner_up=None, and uppercase outside QWERTOP before normal score comparison. That 0.99 is a rule-assigned value, not measured classification accuracy. Removing the overlap (smfWlr) permits normal scoring and selects Korean.

   There is a second boundary: mixed-language arbitration. For example, RKRdkTdjdy becomes RKR았어요. Relaxing the whole-word heuristic alone does not ensure that it wins over an earlier mixed segmentation. This implicates consistency between the heuristic and mixed-language paths, not just one uppercase check. It does not establish that one particular lattice penalty is solely responsible.

   4. Broader rules tested in isolated copies — not installed

   I tried two further eligibility rules while retaining the adjacency restriction, original keys, and exclusion of unrelated Japanese readings:

   Experimental eligibility for additional unknown tokens	Correct ordinary overlap variants
   No Latin vowel (a/e/i/o/u/y) and entirely composed Hangul syllables	78/119
   Entirely composed Hangul syllables, then existing score competition	108/119

   Both introduce new false conversions on synthetic identifier controls that the narrow candidate preserves:

   cmdWL → 층찌
   rmWL  → 그찌
   xmlWL → 틔찌
   rngWL → 궇찌
   

   These are explicitly labeled identifier intentions, not ordinary English dictionary words; their real-world frequency was not measured. They nevertheless demonstrate why “no English vowel” or “valid Hangul syllables” cannot by themselves establish safe automatic conversion. There were six new wrong identifier controls in the initial control set for each expansion. An existing RT → ㄲㅆ result was kept separate and not counted as a new regression.

   Simply raising a confidence cutoff does not separate all the matching cases either. In additional deliberately constructed stress controls, the erroneous dmlWL → 의찌 received about 0.99775, higher than the desired smfWLr → 늘찍 rescue at about 0.99523. Those controls were added after initial inspection, not treated as held-out validation, and the candidates were not retuned to them.

   The scoring-only experiment still leaves 11/119 ordinary variants wrong through mixed-language selection, even when the whole-word heuristic selects the intended Korean. Examples include RKR았어요 and RHaRha하다 instead of 깎았어요 and 꼼꼼하다.

   I do not consider either expansion safe to adopt in its current form. This is not proof that every broader solution is impossible.

   5. Personal learning is an escape hatch, not passive adaptation

   In isolated real-FFI sessions:

   1. Repeating smfWLr without correcting it left the learning store empty and the output unchanged.
   2. Correcting it to Korean once produced a pending correction.
   3. Correcting it the same way a second time produced an explicit learned entry.
   4. A fresh session then selected 늘찍 automatically.
   5. A supported ending extended this to smfWLrgkek → 늘찍하다, but an unrelated unknown form such as sjfWLrgkek still failed.

   Thus deliberate repeated correction can help a token and supported stem/ending combinations. Merely waiting while typing does not teach these decisions. Generic shape preference also cannot overcome this hard English decision: even without the additional #13 eligibility restriction, its maximum bias of 1.6 is below the margin implied by 0.99 (ln(99)/2 ≈ 2.298).

   Status

   I am pausing my candidate as a general fix rather than claiming this issue is solved. Its narrow gains are real, but its lexical boundary misses ordinary forms, and the tested broadenings trade better Korean recall for identifier corruption.

   A promising investigation would need coherent evidence across capitalization, Korean word/form plausibility, English identifier preservation, and mixed segmentation, with independently labeled negative cases—not word exceptions, global lowercasing, or a confidence threshold justified only by these examples.

   The further experiments were confined to isolated source copies and synthetic fixtures. No private learning records, unrelated application input, or machine-specific diagnostics are included here. I am leaving the issue open; these findings are additional reproduction/validation material for the planned fix, not a claim that it cannot be fixed.
3. helloiamnotth3devnicetomeetyou

   added

   bugSomething isn't workingSomething isn't working

   on Oct 22, 2026
4. helloiamnotth3devnicetomeetyou

   closed this as completedin 1b00b6don Oct 22, 2026
5. helloiamnotth3devnicetomeetyou commented on Oct 22, 2026

   

   helloiamnotth3devnicetomeetyou

   on Oct 22, 2026

   Contributor

   More actions

   Fixed in #15, now merged into main.

   Both akfgkfRk and akfgkfRK now select 말할까. A shifted vowel immediately after a Korean doubled-consonant key in an otherwise lowercase key stream uses normal language scoring rather than forcing English. The original key stream, English capitalization and abbreviations, and explicit cycling back to English are preserved.

   Real-model, session, and C FFI regressions passed, along with repository CI. This fix is prepared for 0.10.9; that release has not been published yet. The tests verify replayed key streams, not the physical Shift timing that originally produced them.
6. Ddongddi

   added a commit that references this issue on Oct 23, 2026

   fix: preserve confirmed readings and handle shifted Korean vowels

   ...

   This issue will close once commit 1b00b6d is merged into the 'main' branch.

   1b00b6d