Don't claim shift-command-S for the search window by default

[MiMoHo]

Problem

The search hotkey defaults to shift-command-S. That is Save As… in Microsoft Word and the colour picker in iWork, among others. On a fresh install Flycut silently takes it away from whatever app the user is working in — the report that led to this was simply "Save As… stopped working".

A clipboard manager claiming a shortcut that common, system-wide, without asking, is the wrong default.

What this changes

No default is registered for ShortcutRecorder searchHotkey any more.

The existing code already handles the empty case: the recorder stays empty and toggleSearchHotKey: returns without registering anything, because it guards on ShortcutRecorderEmptyCode. The shortcut therefore reaches the frontmost app exactly as it did before Flycut was installed.

• Users who want the search window assign a shortcut under "Search clipboard hotkey" in Preferences.
• Users who have already assigned one keep it — that value lives in the user domain, not in the registered defaults, so the upgrade is a no-op for them.

The main hotkey (shift-command-V) is untouched.

The documentation was wrong too

help.md and readme.md both promised shift-command-B, while the registered default was keyCode 1, which is S. So the documented shortcut never worked and the one that did work was undocumented. Both files now say the shortcut is unset by default and where to assign one.

Verification

• A test program against the bundled ShortcutRecorder confirms the premise the change rests on: a control that was never assigned a combo reports ShortcutRecorderEmptyCode (−1), so the existing guard is what turns "no default" into "no hotkey" — and assigning a combo lifts the guard again.

ShortcutRecorderEmptyCode          = -1
frischer Recorder, keyCombo.code   = -1  -> registriert NICHTS (gewollt)
nach Zuweisung, keyCombo.code      = 8   -> registriert (gewollt)

• Builds with Xcode 26.5 (xcodebuild -scheme Flycut -configuration Release, BUILD SUCCEEDED), 76 warnings, identical to master built the same way.

Not independently reproduced by a second reviewer: the behaviour a user actually notices — shift-command-S reaching Word again — needs a fresh preferences domain and a key press, and keyboard synthesis is blocked by TCC from a terminal context. The code path is small and the guard it relies on is verified above, but if you would rather see it demonstrated on a clean profile before merging, say so and I will write up the steps.

---

Authored and reviewed with Claude Code using Claude Opus 5 at xhigh reasoning effort. Unlike the other open PRs from this fork, this one was not put through a multi-agent adversarial review — that capacity was exhausted at the time. The claims above are limited to what the test program and the build actually show.

🤖 Generated with Claude Code