Repository navigation
1.0.0 build 30: candidate follows the focused caret, not the mouse - #210
Merged
Merged
Conversation
Records the identity of the locked candidate (commit, run, ZIP, host executable), the behaviour that ships for the first time, and the six screenshots that verify the new caret placement: below the line, mirrored at the right edge, flipped above near the bottom, with no overlap. Also scopes the formal IT-22 run honestly: only the rows this candidate actually changed have to be re-run, the rest cite the 0.1.16 rehearsal and say so. Signed-off-by: wangzhizhou <824219521@qq.com>
The affected rows are the eleven the candidate actually changed, plus eight spot checks on core paths that did not change; everything else cites the 0.1.16 rehearsal with its baseline named. IT-15 can run before the release because the acceptance artifact ships its matching source tarball; the recipe records the two digests and the expected outcome for each comparison (data tables must match byte for byte, executable is expected to differ across SDK 27 vs 26.5). Signed-off-by: wangzhizhou <824219521@qq.com>
All eleven affected rows and eight spot checks pass on 1.0.0 build 29; the remaining rows keep the 0.1.16 rehearsal result with its baseline named, so the gate is closed with an explicit scope rather than a claim that all sixty rows ran again. Signed-off-by: wangzhizhou <824219521@qq.com>
The user's IT-15 run stopped at "expected ... differ: char 22" because set -e aborted on the executable comparison, so the three data tables were never compared at all — and variant-s2t.tsv was missing from the list. Report 208 hit the same abort without noticing. Data tables now compare first (all four, hard failure on any mismatch), the executable comparison explains the SDK mismatch per ADR-033 and only fails when STRICT_BYTES=1, and both digests are printed. Records the IT-15 result (report 218): identity chain, offline rebuild, per-architecture import check, 4/4 identical data tables, zero egress at idle; executable differs because the build used SDK 26.5 and this machine has 27.0. Signed-off-by: wangzhizhou <824219521@qq.com>
…line Records the trial baseline: air and pro now run the same binary (4ad949e6…), pro's config and 593-line dictionary are unchanged and its previous bundle is backed up under uninstalled/bundle.aPZKev. The installer refused the first attempt because IMK relaunched the host within three seconds of the stop; stopping, confirming the process is gone, then installing worked. Notes that as correct protection rather than a defect. Signed-off-by: wangzhizhou <824219521@qq.com>
Typing into an empty field placed the panel at the mouse. caretRect passed allowsEmptyCaret: false to the resolver, whose first line returns nil when length() is zero, so the controller fell straight through to its last resort — the mouse position. The HUD path has always passed true, which is why only the candidate window drifted. The resolver now gets allowsEmptyCaret: true, and the fallback chain is explicit and testable: this round's caret, then the last caret that did resolve, and only then the mouse. Each fallback logs its reason under LAMPYRIS_HUD_DIAG. Build 30. Signed-off-by: wangzhizhou <824219521@qq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
修用户复验 build 29 时发现的缺陷：输入框有焦点、鼠标离得很远时，候选窗出现在鼠标处（报告 219）。
根因
InputController.caretRect()给解析器传了allowsEmptyCaret: false，而解析器第一行是guard hasText || allowsEmptyCaret else { return nil }。只要length() == 0（空输入框，或客户端的length()不含预编辑文本），解析立即返回 nil，caretRect落到最后一档——鼠标位置。HUD 那条路径一直传
true，所以只有候选窗跑偏。修法
allowsEmptyCaret: true。CaretPlacement.fallback(current:previous:mouse:)= 本轮结果 → 上次成功位置 → 鼠标；每档都写
LAMPYRIS_HUD_DIAG原因。lastCaretRect只在解析成功时更新。验证
caret-placement.swift新增回退链三例（本轮优先 / 用上次位置 / 才用鼠标）make verifyPASS；make macos-offline-tests56 文件 / 303 例 PASS装机后请复验：聚焦输入框 → 鼠标移到屏幕另一端 → 打字，候选窗应贴插入点。