Repository navigation
Conversation
xiaoyumuxi
left a comment
There was a problem hiding this comment.
跨 PR 审查(head 9632f520)
结论:没有发现可以从本次差异中确定的阻塞缺陷;当前仍为 Draft,且 mergeable=false。
新增的 Find Action 命令进入命令目录、快捷键映射和 Search Everywhere 的 / 命令搜索模式;已有弹窗重新唤起时显式重置查询与聚焦,关闭时清理模式前缀。静态追踪显示没有另建一套搜索引擎,继续复用既有 Search Everywhere 的数据与窗口。
合并前建议核对真实 AppKit/SwiftUI 键盘交互:⌘⇧A 在工作台打开、在已打开的 Search Everywhere 上切换到命令模式并把光标放在 / 后、Esc 退出后普通搜索不残留前缀;输入法组合输入与其他自定义 keymap 不被抢焦点。还应在项目切换及 module 激活迟到场景检查窗口不会复活到错误项目。新增测试已覆盖部分模式状态,但本轮没有实际运行 GUI。
先同步最新 preview、重跑相关 Search Everywhere 原生点击/焦点测试后再转 Ready。
|
同步进展说明。我在本地把分支变基到最新 preview(
本地已运行并通过: 还没有完成的部分:这台机器磁盘空间不足,Swift 编译中途失败,所以 |
Add a find-action command to the shared keymap catalog with the macOS default Shift-Command-A. It opens Search Everywhere in slash command mode, or switches an already open popup to command mode and refocuses the input. IDEA Classic and Eclipse leave it unbound. Refs 1lck#1177
9632f52 to
4e5fe61
Compare
|
Synced to the latest preview (80101d8). New head is 4e5fe61. The only conflict was in the two Localizable.strings files next to the new Find Branch entries from #1496; both sets of keys are kept. Tests that passed on the new head:
Native check, on a local debug build of this head:
Something I saw that this PR does not cause: Escape did not close the Search Everywhere popup in my run. An unpatched build of preview 80101d8 does the same thing, so it is not from this change. It may only happen with synthetic key events. |
Lithe Review结论: Findings
Scope Check
Suggestions
Summary命令注册、预设覆盖、菜单快捷键和本地化资源保持一致, Verification
|
Opening a project in the same window kept isSearchEverywhereVisible from the previous project. If that project's search module activation was still running, the runtime shutdown cancelled it and the stale task no longer dismissed the popup, because the workspace had changed. The flag stayed true, so Command-Shift-A in the new project skipped activation and Find Action could not recover. prepareForWorkspaceOpen now dismisses Search Everywhere, the way closing a project already resets the search session. A test switches projects before the first activation runs and checks that Find Action opens again in the second project.
|
The P2 finding is real. When a project opens in the same window, 4b7dda2 makes On the Verify Agent Notes failure: |
…ind-action-shortcut # Conflicts: # .agents/notes/implemented/feature/2026-08-15-macos-keymap-customization.md
|
Merged the latest preview into this branch (new head e096b2f). The only conflict was in the keymap customization agent note, where preview moved the scripts into subfolders. I kept the new Checks on the new head:
|
Problem
Issue #1177 lists macOS shortcuts that do nothing in Lithe, and Find Action (Shift-Command-A in IntelliJ) is one of the P0 entries. Search Everywhere already has a commands-only mode when the query starts with
/, but nothing opened the popup in that mode. This PR adds that one shortcut. The rest of the issue (smart completion, Generate Code, refactoring, F4 and so on) needs separate design work, so this refs the issue rather than closing it.Fix
A new
find-actioncommand in the shared keymap catalog defaults to Shift-Command-A on the macOS preset. IDEA Classic and Eclipse leave it unbound, because there is no upstream keymap XML in the tree to confirm their mapping and the command should not quietly inherit the macOS default.It is registered in
LitheActionRegistry, follows the workspace and search-module availability rules, and has a "Find Action…" menu item that uses the effective binding, so remapping, disabling and restoring in Settings > Keymap apply to the menu as well. No new key event monitor is added, and double-Shift and Shift-Command-O still open ordinary Search Everywhere.openFindAction()opens Search Everywhere seeded with/. If the popup is already open, it switches the query back to/and refocuses the input instead of closing. Activation failure goes throughdismissSearchEverywhere(), and dismissing clears a leftover command-mode query so reopening starts clean, while ordinary search drafts are kept.In the view, a small AppKit helper behind the input makes it first responder again each time the popup is shown or reseeded. SwiftUI focus state alone did not bring focus back after AppKit had cleared the responder. The popup panel selects the restored text when it takes focus, so when the text is exactly
/the helper puts the caret after the slash. Typingrunthen gives/runinstead of replacing the slash and falling back to workspace search.The menu strings have English and Simplified Chinese translations. The keymap agent note and the keymap-customization capability record describe the new entry point and its manual checks, and
verificationStatusstayspending.Testing
All of this was run on top of current
preview.KeyboardShortcutTests,SearchEverywhereQueryModeTestsandAppLocalizationTests. The new native popup test runs the real command throughAppModeland takes about 1.35 s.scripts/test-macos.sh --no-parallelran all 3013 tests. The only failures weregitLogQueryMatchesInclusiveAfterAndExclusiveBeforeDatesand the two Plugin UI icon tests, which fail the same way on unmodifiedpreviewon this machine. One Search Everywhere appearance test failed once in that run and then passed in three later runs of every Search Everywhere suite.preview) pass.I have not done the manual run in the app yet (Shift-Command-A from the editor, the sidebar and a second project window), so I'm opening this as a draft, as the repo's PR guidelines ask.
Refs #1177